Gerência de Projetos de Software - julionardi.scalfoni.com.br · Gerência de Projetos – Notas de Aula (v 5.0) – Monalessa Perini Barcellos 6 Escopo, tempo e custo formam o triângulo

UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO

CENTRO TECNOLÓGICO

DEPARTAMENTO DE INFORMÁTICA

GERÊNCIA DE PROJETOS

Notas de Aula (versão 5.1)

Monalessa Perini Barcellos

([email protected])

Obs.: Este material não tem o objetivo de ser um resumo do conteúdo abordado na disciplina. Deve ser utilizado

como um guia que destaca os principais tópicos e conceitos discutidos nas aulas. O conteúdo correspondente aos

tópicos aqui apresentados deve ser aprofundado considerando a bibliografia disponibilizada no programa da

disciplina.

Índice

1. Introdução ______________________________________________________________________________________________ 3

1.1 Organizações ____________________________________________________________ 3

a) O que é uma organização? ________________________________________________ 3

b) Arquitetura Organizacional _______________________________________________ 3

1.2 Projetos, Atividades Continuadas e Organizações ________________________________ 4

1.3 Gerência de Projetos ______________________________________________________ 5

1.4 Ciclo da Gerência de Projetos ________________________________________________ 6

1.5 O Gerente de Projetos ______________________________________________________ 9

1.6 Tipos de Estruturas Organizacionais__________________________________________ 10

1.7 Escritórios de Gerência de Projetos (PMO –Project Management Office) _______________ 13

2. As Áreas de Conhecimento da Gerência de Projetos _____________________________________________ 14

2.1 Gerência de Integração ____________________________________________________ 15

2.2 Gerência do Escopo ______________________________________________________ 16

2.3 Gerência dos Recursos Humanos ____________________________________________ 19

2.4 Gerência do Tempo ______________________________________________________ 24

2.5 Gerência de Custos _______________________________________________________ 28

2.6 Gerência de Riscos _______________________________________________________ 30

2.7 Gerência da Qualidade ____________________________________________________ 33

2.8 Gerência das Comunicações ________________________________________________ 36

2.9 Gerência das Aquisições ___________________________________________________ 37

2.10 Gerência das Partes Interessadas ___________________________________________ 37

3. Um paralelo entre padrões para Gerência de Projetos __________________________________________ 38

Referências ________________________________________________________________________________________________ 39

Atividades

Atividade 1 – Introdução à Gerência de Projetos ________________________________________________________ 40

Atividade 2 – Gerência de Escopo _________________________________________________________________________ 45

Atividade 3 – Gerência de Escopo _________________________________________________________________________ 47

Atividade 4 – Gerência de Recursos Humanos ___________________________________________________________ 48

Atividade 5 – Gerência de Recursos Humanos ___________________________________________________________ 49

Atividade 6 – Gerência de Tempo _________________________________________________________________________ 50

Atividade 7 – Gerência de Tempo _________________________________________________________________________ 51

Atividade 8 – Gerência de Custos _________________________________________________________________________ 52

Atividade 9 – Gerência de Custos _________________________________________________________________________ 53

Atividade 10 – Gerência de Riscos ________________________________________________________________________ 55

Atividade 11 – Gerência de Riscos ________________________________________________________________________ 56

Atividade 12 – Gerência de Qualidade ____________________________________________________________________ 58

Atividade 13 – Gerência de Qualidade ____________________________________________________________________ 59

Atividade 14 – Gerência da Comunicação ________________________________________________________________ 60

Atividade 15 – Gerência da Comunicação ________________________________________________________________ 62

Atividade 16 – Gerência de Aquisições ___________________________________________________________________ 63

Atividade 17 – Gerência de Aquisições ___________________________________________________________________ 64

Atividade 18 – Gerência de Integração ___________________________________________________________________ 65

Gabarito _____________________________________________________________________________________________________ 66

Estudo de Caso: Correspondência Eletrônica nos Correios ____________________________________________ 67

Anexos

Anexo 1 - Métodos de Apoio à Elaboração de Cronogramas ____________________________________________ 75

Anexo 2 – Introdução à Análise de Valor Agregado _____________________________________________________ 80

Gerência de Projetos – Notas de Aula (v 5.0) – Monalessa Perini Barcellos __________________________________________________________________________________________________________

3

Gerência de Projetos

1. Introdução

1.1 Organizações

a) O que é uma organização?

Sob o ponto de vista técnico, uma organização é uma estrutura social formal que utiliza recursos do ambiente para produzir resultados (Laudon e Laudon, 2011).

Sob o ponto de vista comportamental, uma organização é um conjunto de direitos, privilégios, obrigações e responsabilidades que se equilibram durante um período de tempo, mediante conflitos e resolução de conflitos (Laudon e Laudon, 2011).

Pessoas trabalham em organizações relacionando-se com superiores e subordinados. Elas desenvolvem métodos de trabalho e definem que trabalho será realizado, quando, como e por quem.

b) Arquitetura Organizacional

Organizações são compostas por diferentes níveis e áreas funcionais. Apesar de existirem diversas nomenclaturas propostas por diferentes autores, comumente diz-se que as organizações são estruturadas em três níveis (nível estratégico, nível gerencial ou tático e nível operacional) e que esses níveis são ‘atravessados’ pelas áreas funcionais da organização, como, por exemplo, Vendas & Marketing, Recursos Humanos, Manufatura & Produção e Contabilidade & Finanças (Laudon e Laudon, 2011). À estrutura formada pelos níveis e áreas funcionais dá-se o nome de Arquitetura Organizacional, conforme mostra a Figura 1.

Figura 1 – Arquitetura Organizacional.

No nível operacional encontram-se os processos cuja execução garante o funcionamento diário da organização. Em um banco, por exemplo, depósitos e transferências são processos do nível operacional.

No nível gerencial (também chamado nível tático) encontram-se os processos relacionados à monitoração, controle, tomada de decisões e procedimentos

níveis

áreas funcionais

Nível Estratégico

Nível Gerencial

Nível Operacional

Vendas & Marketing

Contabilidade & Finanças

Manufatura & Produção

RH


4

administrativos. No exemplo do banco, a monitoração e controle do alcance às metas diárias são processos do nível gerencial.

No nível estratégico estão os processos que consideram uma visão mais ampla da organização, incluindo seu posicionamento em relação ao mercado. A análise de viabilidade para abertura de uma nova agência bancária ou lançamento de um novo produto são exemplos de processos do nível estratégico.

Em cada nível, também estão as pessoas responsáveis pela execução dos processos: funcionários em geral, gerentes, diretores e executivos.

O funcionamento e a integração entre os processos e as pessoas que compõem a Arquitetura Organizacional podem ser descritos, macroscopicamente, da seguinte forma: no nível estratégico é definido o Planejamento Estratégico da organização, onde constam os objetivos de negócio, estabelecidos com foco na competitividade organizacional e que devem ser alcançados em períodos de tempo determinados (longo, médio e curto prazos). Para esses objetivos são definidos Planos de Ação, que são executados em sua maior parte no nível operacional.

A palavra chave que guia as ações do nível estratégico é competitividade. A questão básica é o que deve ser feito para que a organização seja sempre interessante para o mercado. Por outro lado, a palavra chave que guia as ações do nível gerencial é sobrevivência. A questão básica passa a ser o que deve ser feito para que a organização atinja as metas estabelecidas e, assim, continue funcionando. Por fim, a palavra chave que guia as ações do nível operacional é funcionamento, uma vez que o nível operacional é a ‘água que move o moinho’, ou seja, faz a organização funcionar.

1.2 Projetos, Atividades Continuadas e Organizações

Um projeto pode ser definido como o esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo (PMI, 2012).

Um projeto caracteriza-se por:

(i) ser temporário (tem início e fim definidos);

(ii) produzir resultado exclusivo; e,

(iii) ter elaboração progressiva.

A construção de um hospital, o desenvolvimento de um software e a criação de um novo modelo de carro são exemplos de projetos.

Os projetos podem ser realizados em todos os níveis organizacionais, envolvendo uma ou várias pessoas. Uma organização decide utilizar projetos quando é necessário organizar atividades que não podem ser abordadas nos limites operacionais normais da organização, com o objetivo final de apoiar o alcance às metas estabelecidas no Planejamento Estratégico.

É importante ressaltar que projetos são diferentes das atividades continuadas.

As atividades continuadas, também chamadas de trabalho operacional ou contínuo, assim como os projetos, são realizadas por pessoas, sob a restrição de recursos. No entanto, diferente dos projetos, o trabalho operacional caracteriza-se por ser contínuo e repetitivo.

Os projetos buscam alcançar um determinado objetivo e, quando este é alcançado, o projeto é encerrado. O trabalho operacional busca manter o negócio da organização e, ao alcançar um determinado objetivo, novos objetivos são adotados.


5

Exemplos:

A construção de um shopping é um projeto.

A manutenção (limpeza) é uma atividade continuada.

O desenvolvimento de um software é um projeto.

A operação do software é uma atividade continuada.

Pequenas manutenções são atividades continuadas.

Uma grande manutenção pode ser tratada como um projeto.

Projetos podem ser subdivididos em subprojetos, a fim de facilitar seu gerenciamento. Por exemplo, em um projeto de desenvolvimento de um grande software, composto por diversos módulos, cada módulo pode ser considerado um subprojeto.

Projetos podem, ainda, ser agrupados em programas. Programas são grupos de projetos relacionados que são gerenciados de maneira coordenada para a obtenção de benefícios que não poderiam ser alcançados se os projetos fossem gerenciados individualmente. O gerenciamento de programas se concentra nas interdependências dos projetos e ajuda a determinar a melhor abordagem para gerenciá-los. Como exemplo, pode-se citar o Programa Fome Zero (programa do Governo Federal Brasileiro).

Por fim, é possível agrupar programas, projetos e outros trabalhos em portfólios para facilitar seu gerenciamento eficaz, a fim de atender aos objetivos estratégicos. Em um portfólio, diferente dos programas, é possível encontrar projetos que não sejam interdependentes ou diretamente relacionados. O agrupamento de projetos e outros trabalhos necessários para potencializar o alcance de um objetivo estratégico (por exemplo: maximizar o retorno sobre os investimentos) é um exemplo de portfólio.

Programas e portfólios também podem ser subdivididos, respectivamente, em subprogramas e subportfólios (PMI, 2012).

1.3 Gerência de Projetos

Gerência de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender seus requisitos (PMI, 2012).

Reúne conhecimento, principalmente das seguintes áreas:

Figura 2 – Áreas envolvidas na gerência de projetos.

Gerenciar um projeto inclui (mas não se limita a): (i) identificação das necessidades;

(ii) estabelecimento de objetivos claros e alcançáveis; (iii) balanceamento das demandas conflitantes de qualidade, escopo, tempo e custos; e, (iv) adaptação das especificações, dos planos e da abordagem às diferentes preocupações e expectativas das diversas partes interessadas.

Gerência de Projetos

Área Técnica

Gestão Empresarial


6

Escopo, tempo e custo formam o triângulo de restrições de um projeto (“trio de restrições”). A qualidade é afetada pelo balanceamento desses três fatores.

As partes interessadas de um projeto (também chamadas de stakeholders) são todas as pessoas e organizações envolvidas no projeto ou cujos interesses possam ser positiva ou negativamente influenciados pela execução do projeto ou por sua finalização. São todos os interessados no projeto. Mais comuns:

Gerente do projeto. Cliente/usuário. Organização executora. Membros da equipe de gerenciamento de projetos. Membros da equipe do projeto. Patrocinador (sponsor). Fornecedores. Influenciadores.

A relação entre os principais stakeholders de um projeto pode ser ilustrada por:

Figura 3 – Relação entre as partes interessadas e o projeto.

Importante: Um projeto é considerado bem sucedido se, ao final, seus objetivos foram alcançados e as expectativas dos seus stakeholders foram atendidas ou excedidas.

1.4 Ciclo da Gerência de Projetos

Para facilitar a elaboração progressiva dos projetos, eles são divididos em etapas ou fases. É comum, em cada área específica, serem definidas as etapas que precisam ser realizadas para produzir um determinado produto. Por exemplo, para o desenvolvimento de software, existem diversos modelos de ciclo de vida que descrevem as etapas do desenvolvimento de software (especificação e análise de requisitos, projeto de sistemas, implementação e testes). Exemplos desses modelos são o Cascata, o Espiral e o RAD, entre outros (Pressman, 2011). Esses modelos, tipicamente, explicitam apenas aspectos relacionados ao desenvolvimento do produto.

Diferente das etapas de construção de um produto, que variam de acordo com o

produto, as etapas do ciclo da gerência de projetos são as mesmas para todos os projetos. Elas descrevem o que deve ser realizado ao longo de um projeto. A Figura 4 apresenta o ciclo da gerência de projetos.

Gerente de

projetos

sponsor

Equipe do projeto

Partes interessadas no projeto

PROJETO

Equipe de gerenciamento de

projetos


7

Figura 4 – Ciclo da gerência de projetos.

Iniciação Ocorre no início do projeto ou de uma fase do projeto (quando o projeto é subdividido). Confirma que um projeto, ou fase seguinte do projeto, deve ser iniciado. Concede a aprovação para o comprometimento dos recursos da organização para o projeto ou fase.

Planejamento

Consiste em realizar as ‘previsões’ para o projeto e em determinar o caminho que o projeto deverá seguir. É a referência para o gerenciamento do projeto. Se for mal realizado, dificilmente o projeto alcançará o sucesso.

Por que planejar? Evitar o fracasso. Prever custos, recursos, prazos e riscos. Analisar alternativas. Organizar. Preparar-se para alterações. Poder acompanhar o andamento do projeto. Planejar melhor da próxima vez.

Quando planejar? O planejamento começa de forma macroscópica no início do projeto. O planejamento é revisto e detalhado ao longo do projeto.

Execução

Consiste em colocar em prática os planos registrados na fase de planejamento.

Controle Consiste em acompanhar o andamento do projeto (monitoramento), comparando

os valores planejados com os valores realmente praticados, e em tomar decisões (preparar o replanejamento) baseadas nos desvios percebidos durante o acompanhamento do projeto.

Encerramento

Neste momento o projeto é oficialmente encerrado. Administrativamente, é feita a homologação do produto ou serviço. Os dados e registros do projeto concluído devem ser devidamente armazenados para servirem de referência para projetos futuros e para casos de manutenções.

Atualmente, devido à ampla aceitação e adoção do PMBoK (Project Management Body of Knowledge) (PMI, 2012), as etapas da gerência de projetos têm sido comumente representadas como grupos de processos que precisam ser executados para que um projeto seja realizado. A Figura 5 mostra a representação do PMI para os grupos de processos da gerência de projetos.

Planejamento Execução Controle Encerramento Iniciação


8

Figura 5 – Ciclo do gerenciamento de projetos (PMI, 2012).

Em cada grupo de processos são realizadas diversas atividades. A Figura 6 mostra o nível de atividades, custos e esforço envolvidos em cada grupo de processos ao longo de um projeto

Figura 6 – Nível típico de atividades, custo e pessoal ao longo de um projeto (PMI, 2012).

Na prática, as atividades dos grupos de processos se sobrepõem, pois os projetos dificilmente são executados de maneira linear. Nesse sentido, a Figura 7 apresenta o fluxo existente entre os processos da gerência e, em seguida, a Figura 8 ilustra a sobreposição dos processos.

tempo

Nível de custos, atividades e pessoal

Início do projeto

(Iniciação)

Organização e preparação

(Planejamento)

Execução e controle do trabalho (Execução, Controle) Finalização do

projeto (Encerramento)

Saídas do gerenciamento do projeto

Termo de Abertura do Projeto

Entregas aceitas

Arquivamento dos documentos do projeto

Plano de Gerenciamento do Projeto


9

Figura 7 – Fluxo entre os grupos de processos da gerência de projetos.

Figura 8 – Sobreposição de processos da gerência de projetos (PMI, 2012).

1.5 O Gerente de Projetos É o responsável pelo gerenciamento do projeto. Deve ter sua competência reconhecida pelos demais envolvidos no projeto, embora não precise ter profundo conhecimento técnico, uma vez que sua competência está mais voltada para o entendimento geral e não específico.

Gerentes de qualquer nível hierárquico executam as mesmas funções. As práticas gerenciais, métodos, atividades e tarefas dependem do empreendimento.

Em uma organização, existem gerentes de projeto e gerentes funcionais. A Figura 9 apresenta as funções de cada um no contexto dos projetos.

Iniciação

Planejamento

Execução

Controle

Encerramento

Planejamento

Iniciação Controle

Execução

Planejamento Controle

Controle

Execução Planejamento Execução Encerramento

Controle


10

Figura 9 – Gerente Funcional x Gerente de Projetos.

Gerentes de projeto devem possuir conhecimento relacionado às áreas de especialização necessárias aos profissionais de Gerência de Projetos identificadas na Figura 10:

Figura 10 – Áreas de especialização necessárias aos profissionais de gerência de projetos.

o Conhecimento, normas e regulamentos da área de aplicação: cada área de aplicação, em geral, possui um conjunto de normas, regulamentos e práticas aceitas.

o Entendimento do ambiente do projeto: ambiente cultural e social, ambiente

internacional e político, ambiente físico.

o Conhecimento e habilidade em gerenciamento geral: contabilidade, finanças, aquisições, vendas, marketing, contratos, legislação comercial, fabricação, distribuição, logística, planejamento estratégico, tático e operacional, estruturas organizacionais, comportamento organizacional, administração de pessoal, planos de carreira, tecnologia de informação, etc.

o Habilidades interpessoais: comunicação eficaz, influência sobre a

organização, liderança, motivação, negociação e gerenciamento de conflitos, resolução de problemas.

1.6 Tipos de Estruturas Organizacionais A autoridade do gerente de projetos em uma organização está diretamente

relacionada com o tipo de estrutura organizacional na qual está inserido. A seguir são apresentados os principais tipos de estruturas organizacionais.

Concepção

Estruturação

Implantação

Projeto

Operação

Gerente do Projeto

Gerente Funcional

Planeja, acompanha e controla o trabalho de uma equipe de projeto

(caráter temporário).

Coordena a interface entre o negócio e os profissionais que operam/utilizam o serviço/produto (caráter permanente).

Conhecimento em normas e regulamentos da área de

aplicação

Conhecimento e habilidade de

gerenciamento geral

Habilidades interpessoais

Conhecimento em Gerência de Projetos

Entendimento do ambiente do

projeto


11

Nas figuras 11 a 15, as caixas em verde representam equipes envolvidas em

atividades do projeto e as caixas em vermelho representam a coordenação do projeto.

Figura 11 – Organizações Funcionais.

Vantagens: Estrutura organizacional duradoura. Carreira profissional transparente. Cadeia de comando explícita.

Desvantagens: O gerente de projeto tem pouca ou nenhuma autoridade oficial. Vários projetos disputam recursos limitados e prioridades. Os integrantes do projeto são leais ao gerente funcional.

Figura 12 – Organizações Estruturadas por Projetos.

Vantagens:

O gerente de projeto é a autoridade máxima. O enfoque da organização é o projeto. Os recursos da organização são destinados ao projeto. Lealdade ao gerente do projeto. Comunicação efetiva.

a) Organizações Funcionais CEO*

...

Gerente Funcional

Funcionário

Gerente Funcional

Funcionário

Funcionário

Funcionário

* CEO = Chief Executive Officer

b) Organizações Estruturadas por Projetos ou Projetizada

CEO

...

Funcionário

Gerente de Projetos

Funcionário

Funcionário

Gerente de Projetos

Funcionário


12

Desvantagens: Quando o projeto é finalizado a equipe é desalocada. Uso dos recursos pode não ser eficiente. Duplicação de funções.

c) Organizações Matriciais

Podem ser de três tipos: Matricial Forte: gerente de projeto tem prioridade sobre gerente funcional. Matricial Fraca: gerente funcional tem prioridade sobre gerente de projeto. Matricial Equilibrada: há negociação entre gerente funcional e gerente de projeto.

Figura 13 – Organizações Matriciais Fortes.

Figura 14– Organizações Matriciais Fracas.

Figura 15– Organizações Matriciais Equilibradas.

CEO

...

Funcionário

Gerente Funcional

Funcionário

Gerente Funcional

Funcionário

Gerente de Projeto

CEO

...

Funcionário

Gerente Funcional

Funcionário

Funcionário

Gerente Funcional

Funcionário

CEO

...

Funcionário

Gerente Funcional

Funcionário

Gerente de Projetos

Diretor dos Gerentes de Projetos

Gerente de Projetos


13

Vantagens: Quando o projeto é finalizado, a equipe é alocada em outras atividades na

empresa. A disseminação de informações ocorre na vertical e horizontal. Os recursos escassos são bem utilizados.

Desvantagens: Mais de um gerente para a equipe do projeto se reportar. Grande probabilidade de conflitos. Precisa de pessoal administrativo extra para cumprir as necessidades dos

projetos. Nota: é possível criar estruturas organizacionais compostas que associam mais de um tipo de estrutura organizacional apresentada anteriormente.

Na Tabela 1 são apresentadas as influências do tipo de estrutura organizacional nos projetos.

Tabela 1 - Influências do tipo de estrutura organizacional nos projetos.

Estrutura

Organizacional Funcional

Matricial Projetizada

Projetos Fraca Balanceada Forte

Autoridade do Gerente de

Projetos

Pouca ou nenhuma

Limitada Baixa a

moderada Moderada

a alta Alta a quase

total

Disponibilidade de Recursos

Pouca ou nenhuma

Limitada Baixa a

moderada Moderada

a alta Alta a quase

total

Quem controla o orçamento do

projeto

Gerente Funcional

Gerente Funcional

Misto Gerente

de Projetos

Gerente de Projetos

Papel do gerente de projetos

Tempo parcial

Tempo parcial

Tempo integral

Tempo integral

Tempo integral

Equipe administrativa de gerenciamento de

projetos

Tempo parcial

Tempo parcial

Tempo parcial

Tempo integral

Tempo integral

1.7 Escritórios de Gerência de Projetos (PMO –Project Management Office)

Um PMO é uma estrutura organizacional que padroniza os processos relacionados à gerência de projetos e facilita o compartilhamento de recursos, metodologias, ferramentas e técnicas (PMI, 2012).

Tipicamente, os PMOs estabelecem e mantêm procedimentos e padrões para

gerência de projetos na empresa, armazenando os dados dos projetos já desenvolvidos


14

para que estes possam apoiar os projetos que ainda serão realizados e, além disso, fornecem apoio aos gerentes dos projetos.

Uma vez que um PMO tem conhecimento de todos os projetos de uma organização,

um gerente de PMO pode atuar na análise de viabilidade e priorização de recursos para os projetos, portfólios e programas, visando ao atendimento dos objetivos estratégicos da organização.

Um PMO pode ser implementado de diversas maneiras: a. Um departamento. b. Um grupo de pessoas em algum departamento. c. Um ambiente virtual.

Algumas de suas funções: Prover suporte administrativo; Estabelecer métodos e padrões; Fornecer consultoria e aconselhamentos; Realizar treinamentos; Acompanhar os profissionais de gerência de projetos; Gerenciar recursos compartilhados entre projetos; Monitorar a conformidade dos projetos aos métodos e padrões

estabelecidos; Coordenar a comunicação entre os projetos; Ser interface da área de projetos com a alta gestão.

O gerente de PMO tem uma atuação mais abrangente que um gerente de projeto. Na Tabela 2 são apresentadas algumas comparações entres os dois.

Tabela 2 – Gerente de Projeto x Gerente de PMO

Gerente de Projeto Gerente de PMO Concentra-se nos objetivos especificados para o projeto.

Concentra-se nas mudanças do programa, que podem ser vistas como possíveis oportunidades para melhor alcançar os objetivos de negócio.

Controla os recursos alocados para o projeto, buscando alcançar os objetivos do projeto.

Otimiza o uso de recursos organizacionais compartilhados entre os projetos visando alcançar os objetivos de negócio.

Gerencia as restrições (escopo, tempo, etc.) do projeto.

Gerencia as metodologias, padrões, riscos, oportunidades globais, indicadores e interdependências entre os projetos, no nível organizacional.

2. As Áreas de Conhecimento da Gerência de Projetos

Existem padrões que podem ser utilizados como referência para a definição dos processos da gerência de projetos. Cada padrão determina áreas de conhecimento que representam ‘aspectos’ que devem ser gerenciados em um projeto.

Dentre os padrões mencionados, os mais conhecidos são o PMBoK (Project Management Body of Knowledge), a ISO/IEC 10006 (ISO, 2003) e a ISO 21500 (ISO, 2012) .

As primeiras áreas de conhecimento consideradas pela gerência de projetos se restringiam a três áreas: qualidade, tempo e custos. Em seguida, percebida a influência do escopo nessas áreas, este foi acrescido, evoluindo o formato triangular para um quadrangular. Em seguida, foram definidas outras cinco áreas de conhecimento, resultando em nove áreas (integração, escopo, recursos humanos, tempo, custos, riscos,


15

qualidade, comunicações e aquisições), estruturadas em formato de uma rosácea. No final de 2012, o PMI publicou a 5ª edição do PMBoK, incluindo uma nova área: partes interessadas.

A Figura 16 ilustra a evolução das áreas de conhecimento da gerência de projetos.

Figura 16 – Áreas de conhecimento da gerência de projetos.

A seguir, são apresentados detalhes de cada uma das áreas de conhecimento da

gerência de projetos. Os processos de cada área e suas definições baseiam-se em (PMI, 2012).

2.1 Gerência de Integração

Contém o conjunto de processos necessários para assegurar que todos os elementos (áreas) do projeto estão adequadamente coordenados. Processos:

a) Desenvolver o Termo de Abertura do Projeto: Consiste em desenvolver o documento que formalmente autoriza um projeto ou uma fase do projeto, conhecido como Project Charter (Plano Sumário do Projeto). Esse documento dá ao gerente do projeto a autoridade necessária para aplicar recursos organizacionais a atividades do projeto.

Project Charter (Plano Sumário do Projeto) É o documento que autoriza formalmente um projeto. Reconhece e comunica o escopo aprovado do projeto ao gerente de

projeto, gerentes funcionais e seu pessoal, como uma espécie de ‘contrato’. Em casos de ‘venda’, o próprio contrato firmado entre contratante e contratada pode assumir o papel de Project Charter.

Normalmente é emitido por um gerente externo ao projeto em hierarquia tal que possa fornecer autoridade ao gerente de projeto.

O Project Charter inclui (pelo menos): a necessidade de negócio ao qual o projeto foi designado, a descrição do produto e a designação do gerente.


16

b) Desenvolver o Plano de Gerenciamento do Projeto: Reúne as saídas dos planejamentos de todas as áreas do projeto em um documento: o Plano de Gerenciamento do Projeto. Documenta todas as ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares.

c) Orientar e Gerenciar o Trabalho do Projeto: Consiste em realizar o

trabalho definido no Plano de Gerenciamento do Projeto e bem como mudanças aprovadas para atingir o objetivo do projeto. É aí que a maior parte do orçamento do projeto é gasta.

d) Monitorar e Controlar o Trabalho do Projeto: Consiste em acompanhar,

revisar e registrar o progresso do projeto para atender os objetivos de desempenho definidos no Plano de Gerenciamento do Projeto.

e) Realizar o Controle Integrado de Mudanças: Preocupa-se em registrar as

mudanças do projeto, seus motivos e realizar as alterações necessárias de forma integrada.

f) Encerrar o Projeto: É a finalização de todas as atividades em todos os

grupos de processos de gerenciamento de projetos para encerrar formalmente o projeto ou uma de suas fases.

Na Figura 17 é apresentado um esquema que ilustra o funcionamento da Gerência de Integração.

Figura 17 – Ilustração da Gerência de Integração

2.2 Gerência do Escopo

Abrange os processos requeridos para assegurar que o projeto inclua todo o trabalho necessário e, tão somente o trabalho necessário, para completar de forma bem sucedida o projeto.

A preocupação fundamental compreende definir o que está ou não incluído no projeto. A gerência do escopo inclui os seguintes processos:

contratada

“acordo fechado”

Project Charter

informações iniciais

informações de gerência e

do projeto/produto

Plano de Gerenciamento do Projeto Controle de Mudanças

contratada contratante

homologação

Projetos

dados do projeto

contratante

Termo de Encerramento do Projeto


17

a) Planejar o Gerenciamento do Escopo: Consiste em criar um plano de gerenciamento de escopo que define como o escopo deverá ser definido, validado e controlado.

b) Coletar os Requisitos: É o processo de definir e documentar as necessidades das partes interessadas para alcançar os objetivos do projeto. Neste processo é elaborada a Documentação dos Requisitos do Projeto, bem como um plano para gerenciamento dos requisitos e uma matriz de rastreabilidade dos requisitos.

c) Definir o Escopo: É o processo de definir uma descrição detalhada do escopo do projeto que será a base para as futuras decisões do projeto. Há escopo do produto e do projeto. Seu principal produto é a Declaração do Escopo, a qual deve conter, no mínimo:

- Escopo do produto - Critérios de aceitação de produtos - Entregas do projeto - Exclusões do projeto - Restrições do projeto - Premissas do projeto

d) Criar EAP: É o processo de subdividir as principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis. Isso facilita a realização das estimativas, a definição de baseline para controle de desempenho e a atribuição clara de responsabilidades.

EAP (Estrutura Analítica do Projeto) = WBS (Work Breakdown Structure)

Todo o trabalho a ser realizado no projeto deve estar na WBS. Se não estiver nela, não é trabalho a ser realizado.

Fornece a visão geral do produto a ser gerado e do processo que irá produzi-lo.

Quando a WBS é mal definida, mal detalhada, pode-se esperar um custo final do projeto mais alto que o esperado, devido às inevitáveis mudanças que ocorrerão e mudarão o ritmo do projeto, causando retrabalho, comprometendo o prazo e diminuindo a produtividade e o moral da força de trabalho.

Nota: Para projetos de desenvolvimento de software, o modelo do processo de desenvolvimento pode ser utilizado para elaborar a WBS.

A Figura 18 apresenta um exemplo de WBS.


18

Figura 18 – Exemplo de WBS definida para o projeto de desenvolvimento de um jogo.

Níveis da WBS

O nível mais inferior da WBS é formado pelos pacotes de trabalho e facilita a alocação de recursos e estimativas de custos e prazos.

Os níveis superiores definem os resultados práticos do trabalho e suas subdivisões.

e) Validar o Escopo: É o processo da formalização do aceite do escopo do projeto pelas partes envolvidas. Exige a revisão dos produtos e resultados do trabalho para garantir que tudo foi cumprido satisfatoriamente.

Obs.: A validação do escopo preocupa-se com a aceitação do mesmo. Para avaliar a qualidade do produto, um processo, relacionado à qualidade, é executado (será apresentado na área de conhecimento Gerência da Qualidade).

f) Controlar o Escopo: Consiste em registrar as mudanças, seus motivos, seus impactos, realizando os ajustes necessários e, procurando, ao longo do projeto, influenciar os fatores que criam mudanças. É preciso estabelecer os procedimentos que deverão ser seguidos durante o projeto para registrar e controlar as alterações no escopo.

Na Figura 19 é apresentado o fluxo de um processo de controle de mudanças de escopo.

Projeto Jogos SIS

Requisitos Gerais

Testes Código Arquitetura Software Requisitos do software

Requisitos do jogo

Obs.: WBS meramente ilustrativa, não representando a WBS completa.

Módulos

Personagens

Instrumentos

Idiomas

Sistemas

Telas

Funcionalidades

Arquitetura

Base de Dados

Módulo 1

Módulo 2

Registro de Testes de Integração

Registro de Testes de Sistema

Desenho funcional e técnico


19

Figura 19 – Exemplo de fluxo representando um processo de controle de mudanças do escopo.

A Figura 20 apresenta as interseções entre a Gerência de Escopo e a Gerência de Integração.

Figura 20 – Ilustração da Gerência de Escopo relacionada à Gerência de Integração.

2.3 Gerência dos Recursos Humanos

Inclui os processos necessários para tornar mais efetivo o uso dos recursos humanos do projeto. Inclui os seguintes processos:

a) Desenvolver o Plano de Recursos Humanos: Consiste em identificar, documentar e designar os papéis, as responsabilidades e os relacionamentos de reporte do projeto.

Neste momento devem ser definidas todas as equipes que estarão envolvidas no projeto. Por exemplo, em um projeto de desenvolvimento de software: equipe

Project Charter

informações iniciais

informações de gerência e do projeto/produto

Plano de Gerenciamento do Projeto Controle de Mudanças

“acordo fechado”

Documentação dos Requisitos

Declaração do Escopo

WBS

Termo de Aceitação do Escopo

contratante

Controle de Mudanças do Escopo

Avaliar contexto da

solicitação de

mudança

Submeter

solicitação de

mudança

Negociar termos,

condições e

pagamento

Solicitar aprovação

do cliente

Realizar

mudanças

solicitante avaliador

Aprovada? Documentar fechamento

da solicitação

de mudanças

Obs.: fluxo apenas ilustrativo,

não abrangendo todas as

etapas necessárias a um

controle de mudanças

eficiente.

sim

não

sim

não

Prevista em contrato?

Avaliar impactos

contratante

contratada


20

de gerência, equipe de desenvolvimento, equipe de medição, equipe de gerência de configuração e as assessorias ou consultorias necessárias.

Definidas as equipes, é preciso identificar suas atribuições. Em seguida, o perfil de cada membro deve também ser representado, destacando as funções que serão por ele executadas e as capacitações e habilidades necessárias.

As equipes devem ser representadas seguindo uma estrutura de organização de equipes. Marilyn Mantei propõe três tipos de estruturas para equipes:

a) Democrática Descentralizada: nessa estrutura não há um líder ou gerente permanente. As decisões são tomadas por consenso. Na prática, não funciona muito bem para projetos.

Figura 21 – Organização de equipe: democrática descentralizada.

b) Controlada Descentralizada: nessa estrutura há um gerente geral para o projeto e gerentes secundários ou líderes locais. As decisões de problemas do projeto são tomadas por consenso entre o gerente do projeto e os gerentes secundários. A execução das ações é controlada pelos gerentes secundários. Há comunicação horizontal e vertical. Essa estrutura é comum em projetos que possuem vários módulos, principalmente, se estes são desenvolvidos em paralelo.

Figura 22 – Organização de equipe: controlada descentralizada.

c) Controlada Centralizada: nessa estrutura há um gerente geral para o projeto e os demais membros estão diretamente ligados a ele. Não há líderes secundários. Só há comunicação vertical.

Figura 23 – Organização de equipe: controlada centralizada.

Membro 1

Membro 2 Membro n

Gerente

Líder 1 Líder n

Membro Equipe 1

Membro Equipe 1

Membro Equipe n

Membro Equipe n

Gerente

Membro n Membro 1


21

Para exemplificar uma estrutura de equipe, suponha um projeto composto por três módulos, cujo modelo de processo seja o RAD (Rapid Application Development). A equipe será dividida em três subequipes, tendo cada equipe um líder. As equipes são compostas por 1 analista e 2 programadores. Há, ainda, uma equipe de controle da qualidade composta por três membros (os líderes do projeto e um usuário).

Equipe de Gerência e Equipe de Desenvolvimento

Equipe de Controle da Qualidade

Figura 24 – Exemplo de organização de equipe.

Em seguida, para cada papel representado nas estruturas devem ser indicadas as funções que serão desempenhadas, bem como as características e habilidades necessárias. Por exemplo:

Analistas (A1, A2 e A3): Desempenharão as funções relativas à análise e ao projeto do sistema. Devem ter experiência em projetos anteriores, serem capazes de trabalhar em equipe, ter conhecimento e prática dos conceitos da Orientação a Objetos e sua representação pelos diagramas da UML e da utilização da ferramenta CASE JUDE.

Nota: Uma matriz de responsabilidades pode ser utilizada para mapear as responsabilidades de cada membro do projeto.

A Tabela 3 apresenta como exemplo um fragmento de uma matriz de responsabilidade definida para o projeto do jogo SIS. Vale destacar que a matriz de responsabilidade terá um nível de detalhamento maior quando for definida (ou refinada) após a identificação das atividades do projeto (processo Definir as Atividades, presente na Gerência de Tempo).

Gerente

Líder 3 Líder 2 Líder 1

A1 P1.1 P1.2 A2 P2.1 P2.2 A3 P3.1 P3.2

Gerente

Líder 3 Líder 2 Líder 1 Usuário


22

Tabela 3 - Fragmento de uma matriz de responsabilidade definida para o projeto do jogo SIS.

Atividade Membro do Projeto

Líder 1 Analista 1 Programador 1 Usuário

Definir personagens

A E I C

Definir instrumentos

A E I C

E = Executa A = Aprova C = Consultado I = Informado

b) Mobilizar a Equipe do Projeto: É a alocação, propriamente dita, da equipe ao projeto. Os papéis e responsabilidades definidos serão destinados a uma pessoa (ou grupo de pessoas) na organização. Há três formas de alocação:

i) Negociação: alocação de membros da organização (seleção interna).

ii) Alocação prévia: o projeto já inicia com a equipe pré-definida.

iii) Contratação: recursos externos à organização são contratados para participarem do projeto.

Após definidas as equipes, os profissionais podem ser alocados aos seus papéis, ou seja, estes passam a ser representados pelos nomes dos recursos que as executarão. Por exemplo: Analista 1: João Carlos Azevedo.

Caso não seja possível, nesse momento, alocar os recursos devido à necessidade de informações sobre os períodos em que serão alocados ao projeto, os mesmos podem ser alocados no momento da elaboração do cronograma, quando datas e períodos de trabalho já estarão melhor definidos.

c) Desenvolver a Equipe do Projeto: Envolve o aumento da capacidade das partes envolvidas de contribuir individualmente para melhorar a produtividade da equipe. É necessário que a equipe seja constantemente instigada a melhorar sua performance, sua integração e seus resultados. Existem três teorias clássicas para trabalhar a motivação da equipe e/ou indivíduo:

i) Teoria X e Y de McGregor

Define dois tipos de gerentes: X e Y.

Os gerentes X são aqueles que acreditam que seus subordinados precisam de controle durante todo o tempo, que são incapazes de produzir algo de qualidade se não estiverem sob ‘vigilância’.

Os gerentes Y acreditam que seus subordinados são capazes de realizar bons trabalhos pelo prazer de ‘fazer bem feito’. Confiam na ‘gestão participativa’.

Na prática, o gerente assume, normalmente, uma combinação dos tipos X e Y, de acordo com a equipe, projeto e situação em que se encontram.

ii) A teoria de Maslow:

Fala sobre a pirâmide de necessidades. Os indivíduos buscam alcançar suas realizações seguindo os níveis de uma pirâmide. À


23

medida que cada nível é alcançado, o indivíduo busca motivação para alcançar o nível imediatamente superior.

Figura 25 – Pirâmide de necessidades de Maslow.

iii) Teoria de Herzberg:

Afirma que há dois tipos de fatores: os motivacionais, que são aqueles relacionados com a satisfação do membro da equipe com seu trabalho; e os higiênicos, que os relacionados com a insatisfação do indivíduo. A existência dos fatores higiênicos não leva à motivação, mas sua ausência leva à desmotivação. Exemplo de fator motivacional é o reconhecimento, pelo gerente e/ou equipe, de um trabalho bem realizado. Exemplos de fatores higiênicos são: salário, normas organizacionais e estrutura física.

Também devem ser realizados treinamentos e propostos modelos que motivem o desempenho individual e da equipe, incluindo premiações aos melhores resultados nas avaliações de desempenho.

d) Gerenciar a Equipe do Projeto: Ao longo do projeto é preciso avaliar os resultados de desempenho da equipe e realizar ações necessárias para controlar eventuais desvios. Além disso, conflitos devem ser resolvidos.

Para lidar com as pessoas e papéis definidos no Plano de Recursos Humanos é necessário conhecer algumas técnicas de relacionamento de equipe, algumas teorias e conceitos.

Um dos principais problemas para gerenciar as equipes ao longo do desenvolvimento do projeto é a resolução dos conflitos.

Thamhanin e Wilemon destacam as seguintes fontes potenciais de conflitos: prazos, prioridades de projeto, recursos (mão de obra), questões técnicas, procedimentos administrativos, choques de personalidade e custos. Cada um desses fatores pode assumir uma escala diferente de acordo com a fase de desenvolvimento do sistema.

Para o gerenciamento de conflitos algumas técnicas podem ser utilizadas:

i) Força: uma parte envolvida no conflito ‘força’ a outra aceitar seu ponto de vista.

ii) Panos Quentes: há a priorização dos interesses das partes envolvidas para resolver o conflito. Os resultados nem sempre são os desejáveis, uma vez que o problema, propriamente dito, pode ter sido subestimado.

Autorealização

Estima

Social

Segurança

Fisiológico


24

iii) Negociação: há a busca por uma solução que satisfaça um pouco a cada uma das partes envolvidas. Só deve ser usada quando uma das partes pode abrir mão de algumas de suas convicções.

iv) Solução de Problemas: os envolvidos são colocados frente a frente e a melhor solução para o conflito deve ser encontrada através de consenso.

v) Retirada: consiste em postergar indefinidamente a solução do conflito.

Na Tabela 4 é possível verificar o tipo de solução de cada técnica e seu resultado:

Tabela 4 – Técnicas de resolução de conflitos.

Técnica Tipo Solução

Resultado Importância para metas pessoais

Importância no relacionamento

Retirada Temporária Perde-perde Baixa Baixa

Panos Quentes Temporária Perde-perde Baixa Alta

Negociação Permanente Perde-perde Média Média

Solução de Problemas

Permanente Ganha-ganha Alta Alta

Força Permanente Ganha-perde Alta Baixa

Cada técnica deve ser utilizada em situações específicas, e uma combinação delas pode ser mais eficiente na resolução dos conflitos de forma permanente.

2.4 Gerência do Tempo

Um dos itens mais importantes que devem ser gerenciados em um projeto é o

tempo. A gerência do tempo de um projeto 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.

Normalmente, é muito difícil elaborar o cronograma no início do projeto, pois poucas são as informações obtidas, então, para elaborar o Plano de Gerenciamento do Projeto, em alguns casos, pode ser considerada apenas uma visão macro do processo. Em um momento posterior, quando maiores informações tiverem sido obtidas, o cronograma deve ser refinado.

Sendo assim, a gerência do tempo abrange os processos requeridos para assegurar que o projeto será completado dentro do prazo previsto.

Os processos relacionados à gerência de tempo são:

a) Planejar o Gerenciamento do Cronograma: consiste em estabelecer as políticas, os procedimentos e a documentação necessária para que seja possível elaborar, executar e controlar o cronograma.

b) Definir as Atividades: Consiste em definir quais são as atividades necessárias para produzir os produtos e subprodutos identificados na WBS. Para a definição das atividades deve-se levar em consideração a WBS definida.


25

c) Sequenciar as Atividades: Consiste em identificar e documentar as relações de dependência entre as atividades. No caso de projetos de software, algumas das dependências já estarão definidas através do modelo de ciclo de vida que foi escolhido ao definir o processo de desenvolvimento do projeto. Para representar as dependências, podem ser utilizadas diversas técnicas como, por exemplo, o diagrama de precedência (Figura 27.a) e o diagrama de setas (Figura 27.b).

Figura 27.a – Métodos de sequenciamento de atividades – Diagrama de Precedência.

Figura 27.b – Métodos de sequenciamento de atividades – Diagrama de Setas (ou flexas).

Início

Fim

E

D

C

B A

F

Só representa dependências

Fim - Início

Início

E

C

D

B A

Fim

F

Utiliza dependências: Fim - Início

Fim - Fim Início - Início

Início - Fim

Figura 26 – Exemplo de definição das atividades do projeto de construção de um jogo (SIS).


26

Figura 28 – Exemplo de sequenciamento das atividades do projeto de construção de um jogo (SIS).

d) Estimar os Recursos das Atividades: Consiste em determinar o tipo e quantidades de recursos necessários para realizar cada atividade do cronograma.

e) Estimar as Durações das Atividades: Consiste em determinar o número de

períodos de trabalho que serão necessários para executar as atividades do projeto. É, também, nessa atividade que é estimado o esforço necessário para a realização das atividades do projeto. A estimativa de duração das atividades pode ser feita sob duas abordagens: top-down e bottom-up. Na abordagem top-down, o gerente, inicialmente, realiza as estimativas para todo o projeto e, em seguida, distribui as estimativas entre as atividades/tarefas. Na abordagem bottom-up, o gerente realiza as estimativas para as atividades/tarefas e as estimativas globais são obtidas através do somatório das estimativas individuais.

Para realizar as estimativas podem ser utilizados três tipos de modelos diferentes (BARCELLOS, 2003):

i) Modelos paramétricos: são aqueles que utilizam algoritmos ou fórmulas matemáticas que, recebendo alguns valores como parâmetros, são capazes de calcular as estimativas para o projeto. Exemplos (aplicáveis a software): análise de pontos de função, COCOMO, COCOMO II, etc.

ii) Modelos baseados em analogias: dados de projetos anteriores são

utilizados como referência para realizar as estimativas para o projeto. Para utilizar esses modelos, é preciso ter uma base histórica de projetos, definir uma caracterização para os projetos e


27

determinar um mecanismo para estabelecer a similaridade entre eles, a fim de encontrar os projetos cujos dados serão utilizados nas analogias.

iii) Conhecimento/experiência especialista: consiste no gerente do

projeto utilizar sua experiência pessoal obtida em projetos anteriores para realizar as estimativas do projeto.

Estudos mostram que combinar os três modelos traz resultados mais satisfatórios que a utilização dos modelos de forma independente.

Outras questões sobre a realização de estimativas: É mais difícil no início do projeto, quando as informações a respeito

do projeto ainda são limitadas. Devem ser refinadas ao longo do projeto. É um processo de previsão e não de precisão, por isso uma margem

de erros deve ser considerada.

Figura 29 – Exemplo de realização de estimativas do projeto de construção de um jogo (SIS).

f) Desenvolver o Cronograma: Consiste em formalizar o cronograma, identificando suas datas, caminhos críticos e registrando os marcos e pontos de controle identificados.

Algumas técnicas para desenvolvimento de cronogramas:

i) Análise Matemática

Utiliza cálculos matemáticos para apoiar a elaboração do cronograma.

Exemplos: PERT e CPM

ii) Heurísticas de Nivelamento de Recursos

Consiste na elaboração do cronograma levando em consideração a utilização dos recursos. Normalmente, produz um cronograma com data de fim superior ao proposto pelas técnicas matemáticas convencionais.


28

Algumas vezes, ao elaborar o cronograma, a data final do projeto não satisfaz às necessidades e restrições do projeto. Nesses casos, é necessário aplicar técnicas para compressão do cronograma, que tentam reduzir o prazo do projeto sem afetar o escopo.

i) Crashing (colisão): aumentar os recursos da atividade para terminá-la em menos tempo. Mas para isso é preciso estar atento ao impacto financeiro.

ii) Fast Tracking (caminho rápido): antecipar o início da atividade. Para isso é preciso ter cuidado para evitar retrabalho.

Para um melhor efeito, essas técnicas devem ser aplicadas sobre as atividades do caminho crítico, mas com cuidado para evitar, por exemplo, a mudança do caminho crítico sem muito resultado.

Figura 30 – Exemplo de desenvolvimento do cronograma do projeto de construção de um jogo (SIS).

e) Controlar o Cronograma: Durante o desenvolvimento do projeto, o cronograma deve ser comparado, analisado e revisto sempre que necessário. Sendo assim, os desvios devem ser identificados, o cronograma deve ser alterado de forma a absorver os desvios e as alterações realizadas devem ser informadas às partes envolvidas no projeto.

2.5 Gerência de Custos

Se o tempo é um dos itens mais importantes para a gerência de um projeto, os custos estão no mesmo patamar de importância, ou até em um acima. A gerência de custos de um projeto tem como objetivo elaborar e controlar o orçamento do projeto. Para isso, devem ser previstos os recursos que serão utilizados, seus valores, o tempo de sua utilização e as receitas previstas para o projeto, quando pertinente.

Da mesma forma que ocorre na elaboração do cronograma, para elaborar o orçamento, inicialmente, poucas são as informações obtidas, então, pode ser gerado um orçamento inicial para o Plano de Gerenciamento do Projeto e, quando mais informações


29

forem obtidas (em projetos de software, quando a especificação de requisitos estiver concluída, por exemplo), o orçamento deve ser refinado. É importante ressaltar, também, que as alterações ocorridas no cronograma devem ser estendidas ao orçamento, isto é, se as estimativas de tempo e esforço forem revistas, as estimativas de custos também serão.

Processos:

a) Planejar o Gerenciamento dos Custos: Consiste em estabelecer os procedimentos, políticas e documentos que devem ser utilizados para o gerenciamento dos custos do projeto.

b) Estimar os Custos: Consiste na identificados dos elementos de custos do projeto. Por exemplo, para projetos de software: recursos de hardware, recursos de software, recursos humanos e outras despesas (aluguel, móveis, energia, etc.). Para cada elemento de custo identificado é preciso determinar seu custo unitário1, quantidade necessária e custo total para o projeto. É importante observar que os recursos humanos já foram identificados no Plano de Recursos Humanos e seu tempo de utilização ficou estabelecido no cronograma.

Figura 31 – Exemplo hipotético de estimativas de custos para projeto de software.

c) Determinar o Orçamento: Consiste em utilizar os valores identificados no passo anterior para elaborar o orçamento do projeto, que será a baseline dos custos2 para medir o desempenho do projeto. Aqui, todos os elementos de custos e seus respectivos valores, identificados/registrados anteriormente, devem ser inseridos no orçamento do projeto. Quando pertinente, as receitas previstas para o projeto também devem ser identificadas (origem, data e valor).

d) Controlar os Custos: Durante o desenvolvimento do projeto, o orçamento

deve ser comparado, analisado e revisto sempre que necessário. O controle de custos envolve identificar e documentar o motivo das variações, tanto positivas quanto negativas e adequar o orçamento a elas. Sendo assim, os

1 O custo pode ser referente à compra ou à utilização do recurso. 2 Baseline dos Custos é o orçamento referencial que será utilizado para medir e monitorar o desempenho dos custos do projeto. É desenvolvido através da totalização das estimativas de custos por período.

Recursos Humanos

Recurso Quantidade Valor Unitário Horas Valor Total

Analista 1 R$30,00/hora 176 R$ 5.280,00

Programador 1 R$15,00/hora 104 R$ 1.560,00

Tester 1 R$15,00/hora 40 R$ 600,00

Total R$ 7.440,00

Recursos de Hardware

Recurso Quantidade Valor Unitário Compra/Uso Valor Total

Computador 3 R$ 300,00 Uso R$ 900,00

Scanner 1 R$ 100,00 Uso R$ 100,00

Impressora 1 R$ 150,00 Uso R$ 150,00

Total R$ 1.150,00

Recursos de Software

Recurso Quantidade Valor Unitário Compra/Uso Valor Total

Rational Rose 2 R$ 300,00 Uso R$ 600,00

Oracle 2 R$ 300,00 Uso R$ 600,00

Delphi 2 R$ 300,00 Uso R$ 600,00

Total R$ 1.800,00

Despesas

Recurso Quantidade Valor Unitário Frequência Valor Total

Aluguel 1 R$ 300,00 Mensal R$ 300,00

Total R$ 300,00

Origem:

Gerência

de RH

Origem:

Cronograma

Origem:

Gerência

de Tempo


30

desvios devem ser identificados, o orçamento alterado e as situações de risco, quando acontecerem, devem ser comunicadas às partes interessadas.

2.6 Gerência de Riscos

Segundo o dicionário, o conceito de risco está associado a perigo, a possibilidade de perda ou dano. Para projetos de software essa perda ou dano pode se referir a falta de qualidade do produto, a atrasos de cronograma, a não aderência de orçamentos ou, até mesmo, a falha total do sistema produzido.

Os riscos devem ser planejados no início do projeto e acompanhados ao longo do desenvolvimento do mesmo, buscando evitá-los ou minimizar seus impactos.

Os processos relacionados à Gerência de Riscos são: a) Planejar o Gerenciamento dos Riscos: Define como será a abordagem de

gerência de riscos do projeto.

b) Identificar os Riscos: Consiste em identificar quais são os riscos que o projeto envolve, descrevê-los e classificá-los.

Categorias de Riscos Uma classificação para riscos pode ser: riscos técnicos, riscos de qualidade,

riscos de gerência, riscos organizacionais, riscos de desempenho e riscos externos.

É importante ressaltar que cada organização pode ter uma classificação de

riscos própria. Exemplo de Identificação de Risco Risco: Cliente designado para validação/homologação do sistema é

despreparado para essa função Categoria: Risco de qualidade Contexto: O(s) usuário(s) designado(s) para atuar(em) na

validação/homologação do sistema não possui(em) conhecimento suficiente para realizar essa atividade.

c) Realizar a Análise Qualitativa dos Riscos: Consiste em avaliar a probabilidade de ocorrência do risco e seu impacto sobre o projeto. Algumas formas:

i) Matriz de Graduação

Consiste em tabelas de referência para análise de impacto e probabilidade de riscos. Cada organização pode elaborar sua própria matriz, com valores customizados para suas características.

As escalas podem ser lineares ou não lineares. Escalas não lineares

normalmente são utilizadas para destacar com diferença significativa os riscos com impactos e/ou probabilidades maiores.

Na Tabela 5 é apresentada uma matriz de graduação para

classificação dos impactos dos riscos.


31

Tabela 5 – Matriz de graduação para classificação dos impactos dos riscos.

ii) Matriz Probabilidade x Impacto

Consiste em uma matriz para classificar um risco de acordo com sua possibilidade e impacto. A Tabela 6 é um exemplo de matriz probabilidade x impacto. Os patamares da organização para risco baixo (cinza claro), moderado (cinza escuro) e alto (preto), como apresentado na matriz, determinam o grau do risco.

Tabela 6 – Matriz probabilidade x impacto.

iii) Exemplo Simples de Qualificação de Risco

É possível definir um conjunto de tabelas básicas para iniciar a classificação dos riscos, como o apresentado na Tabela 7. Posteriormente, as tabelas podem ser calibradas. Tabela 7 – Tabelas simples para classificação de riscos.

Objetivos do

Projeto

Muito baixo

.05

Baixo

.1

Moderado

.2

Alto

.4

Muito alto

.8

Custo Aumento

insignificante de

custo

< 5% aumento

de custo

5 – 10%

aumento de

custo

10 – 20%

aumento de

custo

> 20% aumento

de custo

Cronograma Deslocamento

insignificante de

cronograma

Deslocamento

de cronograma

< 5%

Deslocamento

de cronograma

5 a 10 %

Deslocamento

de cronograma

10 a 20%

Deslocamento

de cronograma

> 20%

Escopo Redução de

escopo pouco

perceptível

Áreas

secundárias do

escopo são

afetadas

Áreas principais

do escopo são

afetadas

Redução do

escopo

inaceitável para

o cliente

Item finalizado

do projeto é

efetivamente

sem utilidade

Qualidade Degradação da

qualidade pouco

perceptível

Apenas

aplicações muito

demandadas são

afetadas

Redução de

qualidade requer

aprovação do

cliente

Redução de

qualidade

inaceitável para

o cliente

Item finalizado

do projeto é

efetivamente

sem utilidade

Graduação de Risco para um Risco Específico

Probabilidade (P) Graduação do Risco = P x I

0,9 0,05 0,09 0,18 0,36 0,72

0,7 0,04 0,07 0,14 0,28 0,56

0,5 0,03 0,05 0,10 0,20 0,40

0,3 0,02 0,03 0,06 0,12 0,24

0,1 0,01 0,01 0,02 0,04 0,08

0,05 0,10 0,20 0,40 0,80

Impacto nos objetivos (ex.: custo, tempo e/ou escopo) (I)

Riscos Probabilidade Impacto Peso Prioridade

R1 A B 4 3

R2 B B 2 5

R3 M A 5 2

R4 MA MA 8 1

R5 MB A 3 4

Peso do risco = Peso(probabilidade) + Peso(impacto)


32

d) Realizar Análise Quantitativa dos Riscos: Consiste em avaliar a

probabilidade de ocorrência do risco e seu impacto sobre o projeto de forma numérica. Algumas técnicas:

i) Análise de Sensibilidade: analisa até que ponto a incerteza de cada

elemento do projeto afeta o objetivo que está sendo analisado, quando todos os outros elementos são fixados em sua baseline.

ii) Análise de Árvore de Decisão: apresenta os caminhos possíveis para

uma decisão envolvendo riscos e os valores associados a cada um deles, apresentando qual decisão é melhor para o projeto.

iii) Simulação: analisa os impactos das incertezas detalhadas nos objetivos

do projeto. Consiste em ‘executar’ o projeto várias vezes para obter uma distribuição estatística. Ex.: distribuição normal triangular, beta e técnica de Monte Carlo.

e) Planejar as Respostas aos Riscos: Consiste em determinar quais ações

deverão ser tomadas para reduzir as ameaças aos objetivos do projeto. Alternativas:

i) Evitar/Prevenir: mudar o Plano de Gerenciamento do Projeto para

eliminar o risco. ii) Transferir: tentar passar para terceiros a responsabilidade de

resposta ao risco. iii) Mitigar: estabelecer estratégias antecipadas para evitar que os

eventos causadores do risco aconteçam. iv) Aceitar: a equipe decide não estabelecer estratégia para lidar com o

risco, ou por ele ser praticamente insignificante ou por não ter sido possível estabelecer tal estratégia.

Exemplo de Planejamento de Respostas aos Riscos Risco: Cliente designado para validação/homologação do sistema é despreparado para essa função Plano de Mitigação: estabelecer critérios que devem ser obedecidos para determinar qual usuário será responsável pela validação/homologação do sistema. Nas reuniões iniciais, observar as características dos usuários para, assim, traçar o perfil de cada um deles e destacar possíveis usuários para atuarem nessa atividade e os que não se adequam à atuação na mesma. Plano de Contingência: Avaliar as características dos usuários com os quais foi mantido contato até então e sugerir a alteração do usuário

Tabela de Referência

Influência Sigla Peso

Muito baixo MB 0

Baixo B 1

Moderado M 2

Alto A 3

Muito alto MA 4


33

responsável por executar a atividade de validação/homologação. Analisar e documentar os atrasos ocorridos em função da despreparação do usuário de homologação.

f) Controlar os Riscos: Consiste em garantir a execução do plano de riscos

definido, identificar novos riscos, monitorar riscos residuais e realizar ajustes, se necessário.

2.7 Gerência da Qualidade

A qualidade do produto final é uma preocupação que deverá existir desde o início do projeto e deve ser mantida ao longo de seu desenvolvimento.

A qualidade será controlada através de uma variedade de tarefas associadas à aplicação de métodos, técnicas, realização de revisões técnicas formais, atividades de testes e controle de alterações ao longo do projeto. Para controlar a qualidade do projeto/produto, devem ser estabelecidos procedimentos que serão realizados ao longo do projeto e métodos que serão utilizados para verificar a qualidade do produto final.

O conjunto de procedimentos que buscam garantir a qualidade do projeto e as diretrizes para realização destes devem ser registrados no Plano de Gerenciamento da Qualidade do Projeto.

A gerência da qualidade inclui os processos necessários para garantir que o projeto irá satisfazer as necessidades para as quais ele foi empreendido.

Na gerência de escopo, o processo de Validar o Escopo analisa se os pacotes de trabalho e resultados práticos necessários foram identificados (aceitação). Na Gerência da Qualidade é avaliada a exatidão com que esses itens são produzidos.

É composta por três processos:

a) Planejar o Gerenciamento da Qualidade: Consiste em identificar que padrões de qualidade são relevantes para o projeto e determinar como satisfazê-los.

Os padrões de qualidade podem ser definidos com o apoio de medidas e indicadores, cujos valores esperados são estabelecidos e são utilizados como metas para o projeto. Por exemplo, pode-se estabelecer que a meta para o indicador de aderência ao cronograma do projeto seja 0,9.

b) Realizar a Garantia da Qualidade: Consiste em garantir que os padrões de qualidade adotados no projeto são realmente relevantes. Inclui a realização de auditorias.

c) Realizar o Controle da Qualidade: Envolve monitorar os resultados específicos do projeto para determinar se eles estão de acordo com os padrões de qualidade relevantes e identificar formas de eliminar as causas dos resultados insatisfatórios. Inclui também a avaliação do desempenho do projeto.

Alguns métodos de apoio à gerência da qualidade:

i) Benchmarking: envolve comparar técnicas reais ou planejadas do projeto com as de outros projetos, para gerar ideias de melhoria e fornecer um padrão pelo qual se possa medir o desempenho.


34

ii) Fluxogramação: consiste em representar elementos relevantes para a qualidade através de diagramas para identificar aspectos da qualidade que devem ser tratados pelos padrões de qualidade definidos. Os principais são:

Diagrama Espinha de Peixe (causa e efeito ou Ishikawa)

Auxilia na detecção das causas que podem levar a um problema de qualidade em um projeto.

Exemplo: Identificar as causas de “defeitos de especificação”

Figura 32 – Diagrama causa e efeito.

Fluxograma de Processo

Auxilia a identificação de possíveis problemas durante a execução do processo.

Exemplo: Fluxograma para Elaborar Especificação de Requisitos.

Figura 33 – Fluxograma de processo.

iii) Gráfico de Controle: gráfico que representa os resultados de um processo ao longo do tempo. São utilizadas para determinar se o processo está bom ou se precisa de ajustes (melhorias).

Cliente errado consultado

Cliente forneceu informação errada

Defeitos de Especificação

Incompleta Ambígua

Modificações

Incorreta

Informação desatualizada foi utilizada

Consulta incorreta

Agendar reunião Realizar questionamentos Registrar respostas

Elaborar Especificação de Requisitos Avaliar Especificação de Requisitos Aprovada?

Refinar Especificação de Requisitos

Fim

Início

Não


35

Exemplo: Gráfico de controle para analisar a média diária de horas (no gráfico a representação está em minutos) dedicadas a atividades de manutenção em um projeto.

39,00

40,00

41,00

42,00

43,00

44,00

45,00

46,00

47,00

48,00

49,00

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

semana

méd

ia d

iári

a d

e h

ora

s

Figura 34 – Gráfico de controle para análise de desempenho do projeto.

iv) Diagrama de Pareto: diagrama de frequência que mostra quantos resultados foram gerados por tipo ou categoria de causa identificada. É utilizado para direcionar as ações corretivas (por exemplo, a equipe deverá tratar as causas que estão gerando o maior número de defeitos).

Lei de Pareto: Uma quantidade consideravelmente pequena de causas irá, tipicamente, causar a grande maioria dos defeitos. Normalmente é referenciada como princípio 80/20 (80% dos problemas se devem a 20% das causas)

Exemplo: Diagrama de Pareto para “causas dos defeitos de especificação”

0

10

20

30

40

50

60

70

80

90

100

casos c

om

defe

itos

Incorr

eto

s

Am

bíg

uos

Modifi

cados

Incom

ple

tos

Número de casos com

defeitos

Figura 35 – Diagrama de Pareto para analisar as causas de defeitos de especificação.

Considerações:

I – Controle da Qualidade ao Longo do Desenvolvimento

Durante o desenvolvimento do projeto, é preciso garantir que este esteja progredindo de acordo com os planos estabelecidos. Através dos métodos de acompanhamento será possível realizar o controle da evolução do projeto, garantindo-se, dessa forma, uma melhor adequação do que é praticado em relação ao que foi planejado. Os produtos intermediários, identificados na WBS, bem como o produto final, devem ser

LS

LC

LI

Limite superior

Limite inferior

Limite central (valor esperado)


36

avaliados para que os erros sejam identificados e ações corretivas sejam tomadas para garantir a conformidade com os requisitos e com o Plano de Gerenciamento do Projeto.

Os Marcos e Pontos de Controle

O acompanhamento do projeto deve ser realizado através de pontos chave, onde uma sistemática de controle deve ser adotada. Em cada sistemática, atividades devem ser realizadas, sendo que elas devem ter um ou mais responsáveis.

Os pontos chave acima mencionados são os chamados pontos e marcos de controle do projeto. Os marcos de um projeto são momentos (identificados por um produto ou pela conclusão de uma atividade, por exemplo) onde será realizada uma ‘parada’ para verificar se está tudo seguindo o planejado. Exemplos de marcos em projetos de software são: o fechamento da especificação de requisitos do sistema e entrega de módulos, versões ou do próprio sistema. Os pontos de controle não marcos intermediários, como por exemplo: a avaliação da especificação de requisitos, a avaliação do projeto do sistema e de outros produtos.

Os marcos e pontos de controle devem ser identificados no Plano da Qualidade, bem como os procedimentos a serem realizados. Os pontos e marcos devem ser registrados no cronograma.

II – Qualidade do Produto Final

Da mesma forma que as avaliações de qualidade a serem realizadas durante o desenvolvimento do produto devem ser descritos no Plano de Gerenciamento da Qualidade, os procedimentos a serem aplicados no produto final também devem ser descritos. Exemplos desses procedimentos, em caso de projetos de software, são os testes de aceitação alfa e testes de aceitação beta.

2.8 Gerência das Comunicações

Inclui os processos necessários para regular a apropriada geração, coleta, disseminação, armazenamento e descarte final das informações do projeto.

Todos os envolvidos no projeto devem estar preparados para enviar e receber comunicações e devem compreender como suas comunicações afetam o projeto como um todo.

Processos envolvidos:

a) Planejar o Gerenciamento das Comunicações: Determina as informações e comunicações necessárias às partes envolvidas no projeto: quem precisa de que informação, quando serão necessárias, como serão fornecidas e por quem. Neste momento, layouts de documentos e demais instrumentos de documentação devem ser definidos.

Durante o desenvolvimento do projeto, muitos são os documentos gerados. Documentos que podem representar produtos de uma fase de desenvolvimento, como é o caso da Especificação de Requisitos em projetos de software, que é o produto da fase de Análise, ou documentos utilizados para formalizar acordos, entregas ou tarefas, como é o caso das atas e pautas de reunião, das ordens de serviço e registros de homologação.

Todos os documentos que serão gerados no projeto devem ser registrados no Plano de Gerenciamento das Comunicações. Para cada documento, ou outro instrumento, devem ser identificados: seu conceito, momento em que será utilizado, responsável, interessados e layout. Por exemplo:


37

Especificação de Requisitos do Sistema/Software: documento que traz, de forma clara, as informações, exigências e detalhes necessários à implementação bem sucedida do sistema. É gerado na fase de Análise de Requisitos do Sistema/Software, pelo analista de sistemas e disponibilizado para todos os membros da equipe. Segue o layout definido no arquivo Modelo_ERS, localizado no repositório de padrões da organização.

b) Gerenciar as Comunicações: Consiste em coletar e disponibilizar, de forma regular, as informações necessárias às partes envolvidas.

c) Controlar as Comunicações: Consiste em gerenciar as comunicações para garantir que o plano de gerenciamento das comunicações seja seguido e que as necessidades de informação das partes interessadas sejam atendidas.

2.9 Gerência das Aquisições

Contém o conjunto de processos necessários para realizar a obtenção de bens e serviços externos à organização executora. Processos:

a) Planejar o Gerenciamento das Aquisições: Identifica que necessidades do projeto podem ser melhor atendidas através da contratação de produtos ou serviços fora da organização. Envolve considerações sobre como, o que, quando, quanto e onde contratar. Também identifica os potenciais fornecedores. As aquisições do projeto podem ser detalhadas em um documento chamado Especificação do Trabalho (SOW -Specification of Work). Esse documento descreve o item a ser contratado com suficiente detalhamento para permitir que os potenciais fornecedores possam avaliar se são capazes de atender a solicitação.

b) Conduzir as Aquisições: Compreende obter as propostas dos potenciais fornecedores, aplicar critérios de avaliação às propostas recebidas, selecionar os fornecedores e formalizar os contratos.

c) Controlar as Aquisições: Consiste em acompanhar a execução dos contratos para assegurar que o desempenho dos fornecedores está de acordo com os requisitos contratuais.

d) Encerrar as Aquisições: Compreende a formalização do término dos contratos, armazenando as informações para uso futuro.

2.10 Gerência das Partes Interessadas

Inclui o conjunto de processos necessários para identificar todas as pessoas, grupos ou organizações que podem impactar ou ser impactados pelo desenvolvimento do projeto ou seus resultados, analisar as expectativas das partes interessadas e seu impacto no projeto e desenvolver estratégias de gerenciamento apropriadas para o engajamento eficaz das partes interessadas nas decisões, execução e resultados do projeto.

O gerenciamento das partes interessadas também se concentra na comunicação contínua com as partes interessadas para entender suas necessidades e expectativas, abordando as questões conforme elas ocorrem, gerenciando os interesses e conflitantes e incentivando o comprometimento das partes interessadas com as decisões e atividades do


38

projeto. A satisfação das partes interessadas deve ser gerenciada como um objetivo essencial ao projeto (PMI, 2012).

Os processos relacionados ao gerenciamento das partes interessadas de um projeto são:

a) Identificar as Partes Interessadas: Consiste em identificar todas as pessoas, grupos ou organizações que podem impactar ou ser impactados por uma decisão, atividade ou resultado do projeto; analisar e documentar informações relevantes relativas aos seus interesses, nível de engajamento, interdependências, influência e seu impacto potencial no êxito do projeto.

b) Planejar o Gerenciamento das Partes Interessadas: Consiste em desenvolver estratégias apropriadas de gerenciamento para engajar as partes interessadas de maneira eficaz no decorrer do projeto, com base na análise das suas necessidades, interesses e impacto potencial no sucesso do projeto.

c) Gerenciar o Engajamento das Partes Interessadas: Envolve comunicar e trabalhar com as partes interessadas para atender às suas necessidades/expectativas, abordar as questões à medida que elas ocorram e incentivar o engajamento apropriado das partes interessadas nas atividades do projeto no decorrer do projeto.

d) Controlar o Nível de Engajamento das Partes Interessadas: Consiste em monitorar os relacionamentos das partes interessadas do projeto em geral e ajustar as estratégias e planos para o engajamento das partes interessadas.

3. Um paralelo entre padrões para Gerência de Projetos

Atualmente, existem alguns padrões de apoio à gerência de projetos em geral. Os mais conhecidos são o PMBoK (Project Management Body of Knowledge) (PMI, 2012), que se encontra em sua 5ª edição, a ISO 10006 (ISO, 2003) e a ISO 21500 (ISO, 2012), publicada recentemente.

A ISO/IEC 12207 (ISO, 2008), utilizada para a definição de processos relativos ao ciclo de vida de software, também trata do processo de gerência de projetos, mas de uma maneira macroscópica. O relatório RT 16326 da ISO/IEC fez um mapeamento entre a ISO/IEC 12207, o PMBoK e a ISO 10006, visando à gerência de projetos. Esse relatório foi posteriormente (em 2009) substituído pela norma ISO/IEC/IEEE 16326 (ISO, 2009).

Tanto o PMBoK quanto a ISO 10006 tratam a gerência de projetos como um conjunto de processos (na ISO) ou áreas de conhecimento (no PMBoK). Cada área de conhecimento ou processo, por sua vez, é composto por vários processos ou subprocessos.

Na ISO 10006, os processos são: processo estratégico, interdependências, escopo, tempo, custo, recursos, pessoal, comunicação, risco e suprimentos.

No PMBoK, as áreas de conhecimento são: escopo, tempo, custo, qualidade, recursos humanos, comunicação, riscos, aquisições, partes interessadas e integração.

Esses processos ou áreas de conhecimento são os ‘aspectos’ que devem ser gerenciados em um projeto, isto é, que devem constar no Plano de Gerenciamento do Projeto para, a partir daí, serem executados, acompanhados e controlados.


39

Referências

BARCELLOS, M. P., 2003, Planejamento de Custos em Ambientes de Desenvolvimento de Software Orientados à Organização, Dissertação de Mestrado, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.

ISO 10006 – Quality Management Systems - Guidelines for Quality Management in Projects, 2003, International Organization for Standardization, Geneva, Switzerland.

ISO 21500 – Guidance on Project Management, 2012, International Organization for Standardization and the International Electrotechnical Commission, Geneva, Switzerland.

ISO/IEC 12207 – Systems and Software Engineering - Software Life Cycle Process, 2008, International Organization for Standardization and the International Electrotechnical Commission, Geneva, Switzerland.

ISO/IEC/IEEE 16326:2009(E) - Systems and Software Engineering — Life Cycle Processes — Project Management, 2009, International Organization for Standardization and the International Electrotechnical Commission and IEEE, Geneva, Switzerland.

LAUDON, K., LAUDON, J., Sistemas de Informação Gerenciais – Administrando a Empresa Digital, 2011, 11ª Edição, Editora Pearson, São Paulo – SP.

PMBOK – Project Management Body of Knowledge, 5th Edition, 2012, PMI – Project Management Institute.

PRESSMAN, R.S., Engenharia de Software, 2011, 7ª Edição, McGraw Hill, São Paulo-SP.


40

ATIVIDADES


41

Atividade 1 – Introdução à Gerência de Projetos Para as questões abaixo relacionadas, marque a letra correspondente à alternativa correta.

1. O vice-presidente de marketing se aproxima e solicita que mude a tela de entrada dos

visitantes, no website da empresa, de modo a incluir um nome de usuário de, no mínimo, seis caracteres. Isso é considerado:

a) Iniciação de projeto b) Operação continuada c) Projeto d) Execução de projeto 2. Sua empresa fabrica pequenas utilidades de cozinha. Estão lançando uma nova linha

de produtos utilitários em cores de estilo, com excelentes recursos para cozinhas com pequenos espaços. Esses novos produtos serão oferecidos indefinidamente, começando com o lançamento do catálogo da primavera. Qual das afirmações é verdadeira?

a) Trata-se de um projeto, porque a nova linha de produtos nunca foi fabricada nem

vendida na empresa. b) Trata-se de uma operação continuada, porque a empresa está no ramo de fabricação

de utilitários para cozinhas. O lançamento das novas cores e recursos é apenas uma variação de um processo já existente.

c) Trata-se de uma operação continuada, pois a nova linha de produtos será vendida sem prazo definido. Não é temporária.

d) Não se trata nem de um projeto nem de uma operação continuada. É o lançamento de um novo produto que não afeta as operações continuadas.

3. Um projeto é considerado bem sucedido quando: a) O produto do projeto foi fabricado. b) O patrocinador do projeto anuncia seu término. c) O produto do projeto é transferido para sua área de operação, para tratar aspectos

contínuos ao projeto. d) O projeto alcança seus objetivos e atende ou excede as expectativas dos stakeholders. 4. Você é o gerente de projetos de uma grande construtora. O objetivo do projeto é

construir um conjunto de dependências para acomodar o time de suporte dos Jogos Olímpicos, que chegará em nossa cidade 18 meses a partir da data de início do projeto. Você recebeu um orçamento de US$ 12 milhões para finalizar o projeto. Os recursos são facilmente obtidos. Qual é a principal restrição para esse projeto?

a) Tempo, porque a data não pode ser mudada. b) Custo, porque o orçamento está fechado em US$ 12 milhões. c) Recursos, porque são fixos. d) Qualidade, porque as dependências devem ser funcionais e seguras. 5. Você é o gerente de projetos de uma grande construtora. O objetivo do projeto é

construir um conjunto de dependências para acomodar o time de suporte dos Jogos


42

Olímpicos, que chegará em nossa cidade 18 meses a partir da data de início do projeto. João, um operário especialista em tratores, será necessário neste projeto daqui a 2 meses. Qual das seguintes habilidades você usará para conseguir que João seja designado ao seu projeto?

a) Negociar e influenciar b) Comunicação e organização c) Comunicação d) Solução de problemas 6. Você é um gerente de projetos do setor farmacêutico e decidiu tentar o gerenciamento

de projetos no setor de entretenimento. Qual das seguintes opções é verdadeira? a) Muito provavelmente obterá êxito, pois suas habilidades de comunicação são seu

ponto forte. Você prevê a presença de especialistas técnicos na equipe do projeto para tratarem de assuntos específicos do setor, que você não conhece.

b) Muito provavelmente obterá êxito, pois suas habilidades organizacionais são seu ponto forte. Você prevê a presença de especialistas técnicos na equipe do projeto para tratarem de assuntos específicos do setor, que você não conhece.

c) Muito provavelmente obterá êxito, pois tem um amigo no setor de entretenimentos que te passou todas as informações necessárias. Você prevê a presença de especialistas técnicos na equipe do projeto para tratarem de assuntos específicos do setor, que você não conhece.

d) Muito provavelmente não obterá êxito, pois tem pouco conhecimento técnico no setor de entretenimentos, embora tenha previsto a presença de especialistas técnicos na equipe do projeto para tratarem de assuntos específicos do setor, que você não conhece.

7. Você está gerenciando um projeto para instalar um novo software de postagem que

imprimirá automaticamente as etiquetas e administrará a postagem de cartas registradas e outras encomendas especiais. Você tentou conseguir a colaboração da analista de negócios da empresa, que trabalha no projeto, pois você precisa de algumas respostas. Ela responde com evasivas e informa que o projeto não é sua prioridade máxima. Para evitar outras situações como essa você deve:

a) Definir as obrigações da analista de negócios da empresa muito antes das datas de

vencimento e informar a ela que estará reportando essa conduta ao respectivo gerente funcional.

b) Definir as obrigações da analista de negócios da empresa muito antes das datas de vencimento e informar a ela que espera que as expectativas sejam atendidas, porque o cliente também espera que o projeto cumpra as datas de vencimentos para economizar bastante no envio de correspondência anual.

c) Negociar com o gerente funcional da analista de negócios da empresa durante o processo de Planejamento, para definir as expectativas e solicitar sua participação da avaliação de desempenho anual dessa analista.

d) Negociar com o gerente funcional da analista de negócios da empresa durante o processo de Planejamento, para definir as expectativas e informar ao gerente funcional as exigências do projeto. A anuência do gerente funcional garantirá a colaboração da analista.


43

8. A autoridade concedida a um gerente de projeto pode estar relacionada a: a) Habilidades de comunicação do gerente b) Estrutura organizacional c) Autoridade do gerente desse gerente de projeto d) Habilidade de influenciar do gerente 9. Uma das vantagens da estrutura funcional: a) Todos os funcionários se reportam a um único gerente e têm uma cadeia de comando

explícita. b) Todos os funcionários se reportam a dois ou mais gerentes, mas os integrantes da

equipe mostram lealdade ao gerente funcional. c) A organização está voltada para projetos. d) As equipes são colocalizadas. 10. Você foi designado para um projeto cujos objetivos são direcionar as chamadas dos

clientes para um sistema de Resposta Voz Interativo antes de serem passadas para um atendente. Nesse projeto você estará encarregado da comunicação com a mídia e subordinado ao gerente de projeto encarregado por esse projeto e ao vice-presidente de marketing, que divide a responsabilidade do projeto. Em que estrutura organizacional você trabalha?

a) Funcional b) Matricial fraca c) Estruturada por projetos d) Matricial equilibrada 11. Você foi designado para um projeto cujo objetivo é expandir 4,8 Km da rodovia norte-

sul, através de sua cidade, em duas pistas em cada direção. Nesse projeto você está encarregado pela fase de demolição e subordinado ao gerente do projeto. Você foi contratado por serviço e estará liberado assim que terminar a fase de demolição. Em que tipo de estrutura organizacional você se encontra?

a) Funcional b) Matricial fraca c) Estruturada por projetos d) Matricial equilibrada 12. Quais os cinco grupos de processos no gerenciamento de projetos, em sequência? a) Iniciação, Execução, Planejamento, Controle e Encerramento b) Planejamento, Controle, Iniciação, Execução e Encerramento c) Iniciação, Planejamento, Controle, Execução e Encerramento d) Iniciação, Planejamento, Execução, Controle e Encerramento 13. Em que fase do gerenciamento de projetos existe maior possibilidade de riscos de os

stakeholders influenciarem mais nos resultados do projeto, no início do processo? a) Planejamento b) Execução c) Controle


44

d) Iniciação 14. Você é um gerente de projetos que trabalhando na fase de levantamento de requisitos

e estabelecendo as estimativas para o projeto. Em que grupo de processos você se encontra?

a) Planejamento b) Execução c) Controle d) Iniciação 15. Os membros de uma equipe de projetos reclamam entre si que o gerente de projetos

está solicitando uma série de tarefas que eles não têm tempo de fazer devido às suas funções técnicas na empresa. Um consultor, que naquele local chegava, foi questionado por essas pessoas sobre o que ele achava da situação. Ele achou estranho, porque uma das funções do gerente de projetos é repassar as atividades de maneira tal que todos possam realizá-las no prazo determinado. Sendo assim, ele pediu o cronograma e viu que estava tudo de acordo. Então ele perguntou: “- Quem tem o poder nesta empresa para dar direcionamento sobre o que vocês têm que fazer?” e um deles prontamente respondeu: “O nosso gerente está ali.”. Com essa breve situação, qual deve ser a estrutura organizacional da empresa?

a) Funcional b) Matricial c) Estruturada por projetos d) Coordenada 16. Carla, a patrocinadora do projeto solicita uma reunião ao Alexandre, gerente de

projeto, para verificar o andamento. Alexandre se reúne com sua equipe e solicita uma série de informações. Quais informações terão mais relevância para o patrocinador?

a) Prazo do projeto b) Número de fornecedores c) Custo das máquinas e equipamentos necessários à execução do projeto d) Motivação da equipe 17. As principais fontes de falhas nos projetos são: a) Falta de estrutura matricial forte ou projetizada, definição de escopo deficiente e falta

de plano do projeto. b) Falta de compromisso ou apoio da alta gerência, desarmonia na equipe do projeto e

falta de liderança do gerente de projeto. c) Necessidades dos clientes deficientemente identificadas, uma equipe de projeto

geograficamente dispersa e pouca comunicação com o cliente até o projeto ser entregue.

d) Necessidades dos clientes deficientemente identificadas, requisitos do projeto especificados inadequadamente e planejamento e controle ineficientes.


45

Atividade 2 – Gerência de Escopo

Para as questões abaixo relacionadas, marque a letra correspondente à alternativa correta.

1. O escopo de um projeto está completamente descrito por meio da:

a) Declaração do Escopo. b) WBS em cinco níveis. c) Soma dos produtos e serviços a serem entregues pelo projeto. d) Descrição do produto contida no Project Charter. 2. Um gerente de projeto acredita que modificando o escopo do projeto pode prover

valor adicional ao produto para o cliente. Qual deve ser a primeira atitude do gerente de projeto?

a) Mudar a baseline do escopo. b) Preparar um relatório de impacto de mudanças. c) Convocar uma reunião com o Comitê que aprova as mudanças. d) Adiar a modificação até que a baseline do escopo do projeto seja completado. 3. Espera-se ter mudança no escopo do projeto se:

a) O gerente do projeto fizer estimativas de custo sem ter uma concepção do projeto. b) Houver simplificação (subestimativa) do trabalho a ser realizado. c) O objetivo claro não estiver estabelecido. d) Todas as alternativas anteriores são possíveis. 4. João e sua equipe terminaram a decomposição da WBS do projeto. Para verificar se a

decomposição está correta, ou seja, se há necessidade de maior detalhamento, eles devem:

a) Verificar se cada elemento da WBS é necessário e está claramente definido. b) Verificar se cada pacote de trabalho não exige mais do que 100 horas de trabalho. c) Verificar se todos os pacotes de trabalho podem ser programados, orçados e

designados a uma unidade organizacional (depto., equipe ou pessoa) específica. d) Verificar se os mais altos níveis da WBS têm resultados principais tangíveis e

verificáveis. 5. Em qual dos processos abaixo é elaborada a Declaração do Escopo do Projeto?

a) Iniciação b) Definir o Escopo c) Detalhar o Escopo d) Realizar Controle de Mudanças do Escopo 6. Você está trabalhando em um projeto com escopo semelhante ao de um projeto já

executado anteriormente pela empresa. Qual das seguintes afirmativas é possível considerar?

a) Usar como modelo a identificação das alternativas do projeto anterior. b) Reutilizar a justificativa e análise custo/benefício do projeto anterior. c) Usar a WBS do projeto anterior como modelo. d) Reutilizar a descrição do produto do projeto anterior ao redigir a especificação do

escopo.


46

7. Você construiu a WBS para seu projeto recente. As atribuições do nível 2 foram efetuadas e você solicitou que os gerentes dos subprojetos lhe dessem um retorno em três semanas, com cada uma de suas WBS construídas. Todas as seguintes informações são corretas, exceto:

a) O nível de pacote de trabalho facilita as alocações de recursos. b) O nível de pacote de trabalho é o mais inferior na WBS. c) O nível de pacote de trabalho define os resultados práticos estipulados. d) O nível do pacote de trabalho facilita as estimativas de tempo e custos.


47

Atividade 3 – Gerência de Escopo

Em conjunto com seus colegas, escolha um projeto para o qual você será designado como gerente. Para esse projeto, elabore a declaração do escopo e a WBS para detalhá-lo.


48

Atividade 4 – Gerência de Recursos Humanos


1. No início de um projeto o gerente descobre um problema em uma determinada

atividade. Ele também fica sabendo que um membro da equipe que não fazia parte dessa atividade já havia previsto o problema, porém não comunicou à equipe. Diante desse cenário, qual seria o melhor comportamento do gerente?

a) Punir de alguma forma o membro, pois ele deveria ter alertado sobre o problema. b) Não punir o membro, pois a atividade não estava sob responsabilidade dele. c) Reunir a equipe no sentido de aumentar o nível de comprometimento individual e

coletivo. d) Esquecer esse detalhe e focar a solução do problema. 2. Você vai montar a equipe do projeto e percebe que dois dos profissionais mais

importantes não possuem um bom relacionamento entre si. Qual seria, a princípio, a melhor solução?

a) Promover uma conversa entre eles para descobrir a fonte do mau relacionamento. b) Alocar apenas um deles ao projeto. c) Alocar ambos e aguardar para que eles se entendam ao longo do projeto. d) Alocar ambos e deixar claro que não serão admitidos problemas de relacionamento no

ambiente do projeto. 3. Entre os fatores abaixo, qual representa fonte geradora de conflitos menos comum

durante o desenvolvimento do projeto? a) Prazos b) Prioridades do projeto c) Custos d) Questões técnicas 4. Os membros da equipe entram em confronto sobre a definição das prioridades entre

determinadas atividades do projeto. A definição dessa prioridade dele ser estabelecida:

a) Pelos envolvidos no conflito. b) Pelo gerente do projeto. c) Pela gerência funcional. d) Pelo cliente. 5. Você é um excelente gerente de projeto. Sua equipe, os stakeholders e a alta gerência o

respeitam muito. Quando toma suas decisões, os outros seguem suas orientações como resultado de seu:

a) Poder de referência. b) Poder de especialista. c) Poder legítimo. d) Poder de punição.


49

Atividade 5 – Gerência de Recursos Humanos

Para o projeto que você utilizou na Atividade 3, defina a equipe que será alocada, sua estrutura, responsabilidades e perfis de cada membro.


50

Atividade 6 – Gerência de Tempo

Para as questões abaixo relacionadas, marque a letra correspondente à alternativa correta. 1. O controle do cronograma se preocupa com todas as atividades abaixo, exceto: a) Influenciar os fatores que criam mudanças no cronograma para garantir que estas

sejam benéficas. b) Determinar que o cronograma foi alterado. c) Gerenciar as mudanças reais, quando e como elas ocorrerem. d) Alterar o cronograma baseado em demanda do cliente. 2. Fast-tracking significa: a) Reduzir a duração de atividades do caminho crítico para diminuir o tempo do projeto. b) Reduzir a duração do projeto através de redefinição de relacionamentos lógicos entre

atividades. c) Utilizar somente os melhores recursos para terminar o trabalho o quanto antes. d) Coordenar esforços com outros projetos para reduzir o atrito administrativo. 3. Caminho crítico é aquele que: a) Demora mais tempo para se completar. b) Deve ser feito antes de quaisquer tarefas. c) Permite flexibilidade para programar tempo de início. d) Não é afetado pelo atraso de outras atividades. 4. Você é um gerente de projetos trabalhando em um projeto de pesquisa para um novo

remédio. O cronograma preliminar excede a data de vencimento e um requisito de verba federal. O gerente do departamento concordou em liberar dois recursos a mais para trabalharem em seu projeto, com o objetivo de cumprir a data do requisito da verba federal. Ao utilizar os recursos para agilizar as atividades você estará aplicando:

a) Crashing (colisão) b) Fast Tracking (caminho rápido) c) Nivelamento de recursos d) Ajuste no calendário de recursos 5. São técnicas de apoio ao cronograma, exceto: a) PERT e CPM b) Gráfico Gantt e Gráfico de Marcos c) PERT e GERT d) Analogias e Técnica Monte Carlo


51

Atividade 7 – Gerência de Tempo

Elabore o cronograma para o projeto cuja WBS foi definida na Atividade 3. Represente a rede de atividades através de um diagrama de precedência.

Id Atividade Predecessoras Duração Data Início Data Término Recurso Humano


52

Atividade 8 – Gerência de Custos


1. Para realizar a estimativa dos custos do projeto é necessário saber, exceto: a) Os tipos de recursos necessários. b) A quantidade de recursos necessários. c) As receitas previstas para o projeto. d) As despesas gerais do projeto. 2. Qual a relação entre o cronograma e o orçamento? a) Nenhuma, o cronograma é utilizado para gerenciar o tempo e o orçamento par

gerenciar os custos. b) Para elaborar o orçamento, o cronograma deve estar definido para que seja possível

analisar a utilização dos recursos para estimar os custos e, após o orçamento global estar pronto, este deve ser distribuído ao longo do cronograma.

c) Para elaborar o cronograma, é preciso que o orçamento esteja definido para que seja possível alocar os recursos de acordo com o valor estabelecido no orçamento.

d) A relação entre cronograma e orçamento se dá devido à gerência de escopo do projeto. 3. Um ‘desvio’ no cronograma, impacta no orçamento: a) Normalmente, pois a maioria das alterações do cronograma requer mudanças no

orçamento. b) Dificilmente, pois a maioria das alterações do cronograma não requer mudanças no

orçamento. c) Sempre, pois não há como alterar o cronograma sem que as mudanças sejam

cascateadas para o orçamento. d) Nunca, pois não há relação entre eles. 4. Controlar o orçamento significa: a) Influenciar os fatores que criam mudanças no orçamento para garantir que estas

sejam benéficas. b) Determinar que o orçamento foi alterado. c) Gerenciar as mudanças reais, quando e como elas ocorrerem. d) Todas as repostas se aplicam. 5. Você é um gerente de projetos trabalhando em um projeto de pesquisa para um novo

remédio. O cronograma preliminar excede a data de vencimento e um requisito de verba federal. O gerente do departamento concordou em liberar dois recursos a mais para trabalharem em seu projeto, com o objetivo de cumprir a data do requisito da verba federal. Ao utilizar os recursos para agilizar as atividades você estará aplicando crashing. Qual o principal cuidado em relação ao orçamento, ao aplicar essa técnica?

a) O orçamento não sofrerá alterações, uma vez que a técnica foi aplicada no contexto de

tempo do projeto. b) O orçamento deverá ser revisto, pois a utilização de mais recursos aumentará o custo

do projeto. c) Depois que o projeto for finalizado, o orçamento deverá ser alterado para registrar os

custos adicionais gerados pela aplicação da técnica. d) Nenhuma das respostas se aplica.


53

Atividade 9 – Gerência de Custos

Elabore o ‘orçamento global’ para o projeto cujo cronograma foi definido na Atividade 5. É importante ressaltar que em um projeto, o orçamento, para ser efetivo, deve ser distribuído ao longo do cronograma e/ou WBS.

Tipo de Recurso: Recursos Humanos

Recurso Quantidade Valor Unitário Horas Valor Total

Total com Tipo de Recursos: Recursos Humanos

Tipo de Recurso:

Recurso Quantidade Valor Unitário Valor Total

Total com Tipo de Recurso:


54

Tipo de Recurso:

Recurso Quantidade Valor Unitário Valor Total

Total com Tipo de Recurso:

Despesas

Recurso Quantidade Valor Unitário Frequência Valor Total

Total com Despesas

Total Geral


55

Atividade 10 – Gerência de Riscos


1. Em face a um evento de risco com baixa probabilidade e impacto muito baixo sobre o

projeto, qual estratégia não deveria ser adotada: a) Aceitar b) Evitar c) Mitigar d) Nenhuma das anteriores. 2. Um bom gerenciamento de riscos em projetos implica em diminuir: a) Custos b) Prazos c) Incertezas d) a e b 3. Seu fornecedor de equipamentos deixou uma mensagem de voz em seu celular

comunicando que devido a uma tempestade de neve, os produtos por você solicitados sofrerão um atraso na entrega. O fornecedor pediu que você retornasse a ligação. Isso caracteriza um:

a) Risco secundário b) Plano de Contingência c) Risco d) Evento causador de risco 4. No caso da questão 3, para contornar a situação até a chegada dos equipamentos,

alugou equipamentos temporariamente. É uma estratégia de risco para: a) Transferir a responsabilidade pelo risco. b) Aceitar os efeitos do risco. c) Reduzir (contingenciar) os efeitos do risco. d) Prevenir os efeitos do risco. 5. É incorreto afirmar sobre o Gerenciamento de Riscos: a) No processo Planejar o Gerenciamento dos Riscos é elaborado o Plano da Gerência de

Riscos. b) Trata a descrição dos riscos e eventos potenciais que podem causar os riscos

(gatilhos). c) Só deve existir em projetos que se caracterizam por riscos explícitos. d) Documenta as tolerâncias a riscos das partes envolvidas e o planejamento das

respostas aos riscos.


56

Atividade 11 – Gerência de Riscos

Para seu projeto, identifique alguns riscos, faça a priorização e apresente planos de contingência e mitigação para cada um deles.

(1) Identificação Risco 1: Categoria: Contexto:

Risco 2: Categoria: Contexto:

Risco 3: Categoria: Contexto: (2) Priorização

Riscos Probabilidade Impacto Peso Prioridade Risco 1 Risco 2 Risco 3 Usar a graduação:

Nível Peso Muito baixo 0

Baixo 1 Moderado 2

Alto 3 Muito Alto 4

Peso (risco) = peso (probabilidade) + peso (impacto)


57

(3) Plano das respostas (Plano de Contingência e Plano de Mitigação)

Risco 1: Plano de Mitigação: Plano de Contingência:




58

Atividade 12 – Gerência de Qualidade


1. Ao verificar os resultados da execução de um processo, o gerente do projeto observa que existe uma causa especial que está provocando a instabilidade do processo. Dentre as alternativas abaixo, qual seria a mais indicada para resolver o problema?

a) Reunir-se com a gerência, elaborar um diagrama de causa e efeito, analisar o relacionamento entre cada causa potencial e seu grau de influência na causa especial e traçar um plano de ação para eliminar todas as causas.

b) Reunir-se com a equipe do projeto, elaborar um diagrama de causa e efeito, analisar o relacionamento entre cada causa potencial e seu grau de influência na causa especial, colocar as causas identificadas em um diagrama de Pareto para identificar aquelas onde as ações corretivas deverão se concentrar.

c) Reunir-se com a gerência, elaborar um diagrama de causa e efeito, analisar o relacionamento entre cada causa potencial e seu grau de influência na causa especial, colocar as causas identificadas em um diagrama de Pareto para identificar aquelas onde as ações corretivas deverão se concentrar.

d) Todas estão corretas.

2. Durante uma reunião de revisão de status de um projeto de um sistema de

informações para um cliente, a equipe observou que poderia ser facilmente construído um gráfico que permitiria ao cliente uma identificação mais rápida de informações importantes no sistema. Essas informações estavam previstas para serem apresentadas em planilhas, cujo formato dificultava a interpretação. Qual seria a melhor decisão do gerente nesse caso?

a) Autorizar a equipe a gerar o gráfico e fazer uma ‘surpresa’ ao cliente, demonstrando

boa intenção em agregar valor. b) Pedir à equipe para ignorar a sugestão. c) Analisar o impacto da modificação e submetê-la à aprovação do cliente. d) Negociar a implementação do cliente, acrescentando tempo e custos bem maiores que

os necessários, para compensar a ideia da equipe.

3. Dentre as alternativas abaixo, qual não tem aplicação na gerência de qualidade de um projeto?

a) Diagrama de Pareto b) Diagrama Causa e Efeito c) Diagrama PERT d) Fluxogramas 4. Assinalar a correta: a) Causas aleatórias indicam que o processo está fora de controle. b) Causas frequentes estão relacionadas ao processo. c) Causas aleatórias, em geral, são mais fáceis de ser identificadas. d) Causas frequentes, em geral, são mais fáceis de ser identificadas.


59

Atividade 13 – Gerência de Qualidade

Para o projeto escolhido anteriormente: (1) determine alguns padrões de qualidade relevantes (2) determine marcos de controle e, pelo menos para um deles, o procedimento que poderá ser realizado para verificar a qualidade do projeto.


60

Atividade 14 – Gerência da Comunicação


1. Você acumulou informações sobre o projeto e precisa distribuir algumas informações

importantes que acabou de receber. Todas as opções a seguir são ferramentas para distribuição de informações exceto:

a) E-mail b) Videoconferência c) Banco de dados d) Mensagem de voz 2. Entre os comportamentos listados abaixo, um não é aceitável durante uma reunião de

projeto. Identifique-o. a) Distribuir a agenda da reunião antecipadamente. b) Começar no horário marcado mesmo se poucos participantes estiverem presentes. c) Permitir interrupções orais pelos participantes que tiverem ideias criativas. d) Resumir as decisões chave à medida que a reunião prossegue. 3. A sobrecarga de informações pode trazer problemas para o projeto. Cabe ao gerente

de projeto garantir que a informação que mostra o andamento e o progresso do projeto tem valor para os interessados. Para identificar quais medidas serão utilizadas, uma análise das necessidades de informações dos interessados deverá ser feita. Isso está disponível através de:

a) Baseline do projeto b) Plano de Gerência da Comunicação c) Metodologia de Gerenciamento de Projetos d) Critérios e estratégias do projeto 4. Um dos objetivos do Plano de Gerência das Comunicações é proporcionar informações

sobre: a) Experiência e nível de conhecimento dos participantes. b) Métodos que serão utilizados para liberar recursos do projeto quando estes não forem

mais necessários. c) Métodos para obter, armazenar e distribuir as informações do projeto. d) Estrutura organizacional em que o projeto se insere. 5. Seu projeto está avançando conforme o planejado. A equipe do projeto desenvolveu um programa de demonstração de produto que o departamento de vendas irá utilizar em apresentações de marketing para clientes potenciais. O que você deverá fazer na próxima reunião de status com os envolvidos no projeto? a) Reportar o progresso do programa de demonstração e identificá-lo como tarefa

concluída. b) Apresentar uma prévia do produto (demo) e solicitar aprovação e assinatura. c) Revisar a documentação do produto demo e obter aprovação e assinatura. e) Relatar que o demo foi identificado como tarefa concluída no sistema de restauração

de informação.


61

6. O gerente de projetos, frequentemente, realiza reuniões com sua equipe. Essa

ferramenta, se bem aplicada, pode trazer muitos benefícios para o projeto, mas, se mal aplicada, pode transformá-lo em fracasso. As reuniões não podem desperdiçar o tempo dos participantes do projeto. Não há nada mais desagradável do que sair de uma reunião com a sensação de tempo perdido. Que ações o gerente de projetos poderá realizar ao conduzir as reuniões, para torná-las mais produtivas?

a) Para agilizar a reunião, deve evitar discussões e tomar as decisões pelo grupo, mas não

deixando de comunicá-las, afinal, o gerente de projetos deve ser um grande comunicador.

b) Como gerente, você pode ser bem liberal e democrático, confiando em sua equipe, afinal são todos adultos e podem decidir por consenso.

c) Resumir, com certa frequência, os tópicos discutidos com o grupo durante a reunião, mantendo todos alinhados e devidamente informados das decisões.

d) Trazer para reuniões apenas as novas ideias e comunicar as mudanças que têm ocorrido.


62

Atividade 15 – Gerência da Comunicação

Para seu projeto, defina alguns documentos necessários, seu conteúdo, quem deve elaborar, a quem deve ser enviado e qual mídia deverá ser utilizada para o envio.


63

Atividade 16 – Gerência de Aquisições

Para as questões abaixo relacionadas, marque a letra correspondente à alternativa correta. 1. Qual dos processos abaixo não faz parte da Gerência de Aquisições? a) Controlar as Aquisições b) Encerrar as Aquisições c) Conduzir as Aquisições d) Selecionar Fornecedores das Aquisições 2. Para que servem as reuniões de licitação/concorrência? a) Divulgar as propostas dos fornecedores. b) Assinar o contrato. c) Transmitir informações em igualdade para todos os fornecedores potenciais. d) Estabelecer o valor mínimo das propostas. 3. A auditoria de aquisição, realizada no encerramento do contrato, serve para: a) Conceder bônus ao vendedor. b) Identificar sucessos e falhas no processo de aquisição. c) Aceitar formalmente o produto entregue. d) Todas as respostas estão corretas. 4. O que deve ser descrito na SOW (Specification of Work)? a) A lista de fornecedores potenciais e os valores de suas propostas. b) Os critérios de seleção dos fornecedores. c) O desempenho do fornecedor que está cumprindo o contrato. d) A descrição detalhada do produto/serviço a ser contratado. 5. Quando um fornecedor não atende as necessidades do seu projeto, onde pode estar o

problema? a) Na SOW, pois se estiver mal elaborada, o produto/serviço não estará descrito

corretamente. b) Nas auditorias, que podem estar sendo mal realizadas e levando à aprovação de um

produto/serviço insatisfatório. c) No mau desempenho do fornecedor, por não cumprir as especificações contratuais. d) Todas as alternativas são possíveis.


64

Atividade 17 – Gerência de Aquisições

Para seu projeto, identifique quais são os produtos e/ou serviços que deverão ser adquiridos fora da sua organização, caracterizando a necessidade da Gerência de Aquisições.


65

Atividade 18 – Gerência de Integração


1. O Plano de Gerenciamento do Projeto é utilizado para: a) Aprimorar habilidades de gerência em geral. b) Facilitar a comunicação entre os interessados. c) Fornecer uma medida de progresso. d) Desenvolver ações corretivas. 2. Para a equipe do projeto, o documento mais importante para integrar as atividades

durante a execução do projeto é: a) Plano do Gerenciamento do Projeto b) Declaração do Escopo c) Baseline do Escopo d) Curvas S 3. Um exemplo de mudança ocorrida no projeto que deve ser analisada pela Gerência de

Integração é: a) Atraso no cronograma b) Ocorrência de riscos c) Perda de qualidade d) Todos são exemplos de modificação que exigem decisões integradas. 4. Para Realizar o Controle Integrado de Mudanças, deve-se utilizar: a) Gerenciamento de Configuração b) Análise de desempenho c) Softwares de apoio à Gerência de Projetos d) Todas estão corretas 5. O gerenciamento de configuração é muito importante para a realização do controle

integrado de mudanças. Ele envolve: a) Controle do aumento de custo do projeto. b) Identificação dos itens do projeto, seu status inicial e suas modificações. c) Teste de sistemas. d) Correção de problemas.


66

Gabarito Atividade 1

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 B A D A A A C B A D C E A A A C D

Atividade 2 1 2 3 4 5 6 7 C B D C B C C Atividade 4

1 2 3 4 5 C A C B A

Atividade 6

1 2 3 4 5 D B A A B

Atividade 8

1 2 3 4 5 C B A D B

Atividade 10

1 2 3 4 5 B C D C C

Atividade 12

1 2 3 4 B C C B

Atividade 14

1 2 3 4 5 6 C C B C A C

Atividade 16

1 2 3 4 5 D C B D D

Atividade 18

1 2 3 4 5 B A D D B

Gerência de Projetos – Notas de Aula (v5.0) – Monalessa Perini Barcellos __________________________________________________________________________________________________________

67

ESTUDO DE CASO: CORRESPONDÊNCIA ELETRÔNICA NOS CORREIOS 3

A presidência dos Correios vislumbrou a possibilidade da empresa apresentar para

seus clientes um novo serviço que foi denominado Correspondência Eletrônica. Esse

serviço consiste em receber documentos (contas, cartas, faturas, telegramas e

propagandas) dos seus clientes em meio eletrônico (email, site dos Correios ou via EDI –

Exchange Data Interchange) para que estes sejam transmitidos eletronicamente para as

agências mais próximas dos destinatários, onde serão impressos e entregues com maior

rapidez e segurança, reduzindo os custos para os clientes. Os documentos recebidos nas

agências não podem ser encaminhados para o destinatário final por meio eletrônico,

sendo de responsabilidade das agências a impressão e envio.

Após o serviço ter sido proposto e aprovado pelo Conselho de Administração dos

Correios, o presidente designou ao diretor executivo o desenvolvimento de um projeto

piloto que propiciará a disponibilização do serviço em 4 agências (uma em cada capital da

região Sudeste) no prazo de seis meses, utilizando, no máximo R$ 1.000.000,00.

A data de início do projeto é 01/10/2014.

A primeira utilização do serviço terá 50% de desconto para os 3 maiores clientes

de cada uma dessas agências. Os funcionários deverão ser treinados e deverá ser realizada

divulgação do novo serviço pelo site dos Correios e através de cartazes nas agências. A

distribuição dos cartazes para as agências é de responsabilidade dos Correios.

Após a implantação do serviço, será realizada uma análise de viabilidade

considerando os primeiros 4 meses de utilização para decidir por sua expansão.

O gerente designado para o projeto terá autoridade para utilizar recursos

financeiros da empresa, conforme limitação do orçamento do projeto e terá prioridade

para recrutar pessoal dos diversos departamentos, incluindo o Departamento de

Tecnologia de Informação.

Vale ressaltar que o Departamento de Tecnologia dos Correios possui certificação

ISO 9000:2000, sendo assim, o desenvolvimento da solução precisará atender os

requisitos estabelecidos pela norma, bem como estar em conformidade com os padrões de

interface dos demais sistemas utilizados nos Correios.

3 Utilizado para exemplificar uma solução para as atividades 3, 5, 7, 9, 11, 13, 15 e 17.

CENTRO TECNOLÓGICO

DEPARTAMENTO DE INFORMÁTICA

DISCIPLINA: GERÊNCIA DE PROJETOS PROFESSOR(A): MONALESSA PERINI BARCELLOS EMAIL: [email protected]


68

ESTUDO DE CASO: CORRESPONDÊNCIA ELETRÔNICA NOS CORREIOS

SOLUÇÃO NOTA: Inclui apenas alguns aspectos de cada área de conhecimento, não apresentando um plano completo para nenhuma delas. ATIVIDADE 3 1) Declaração do Escopo Projeto: Correspondência Eletrônica nos Correios Justificativa: Com a crescente evolução da Tecnologia de Informação, associada às telecomunicações, vem diminuindo o volume de documentos transportados pelos Correios. Para que a empresa acompanhe e se valha dessa evolução tecnológica, é necessário buscar alternativas de serviços para seus clientes. Dessa forma, o serviço de Correspondência Eletrônica se posiciona como estratégico para a empresa, tendo sido aprovado pelo Conselho de Administração dos Correios. Produto: O projeto deve prover uma solução, a ser utilizada em 4 agências (uma em cada capital da região Sudeste), que permita o recebimento de documentos (contas, cartas, faturas, telegramas e propagandas) dos seus clientes em meio eletrônico (email, site dos Correios ou via EDI – Exchange Data Interchange) para que estes sejam transmitidos eletronicamente para as agências mais próximas dos destinatários, onde serão impressos e entregues com maior rapidez e segurança, reduzindo os custos para os clientes. Objetivos do projeto: disponibilizar em 4 agências dos Correios (Rio de Janeiro, São Paulo, Belo Horizonte e Vitória), no prazo de 6 meses e com um custo máximo de R$ 1.000.00,00 o serviço de Correspondência Eletrônica para análise de viabilidade de expansão do serviço. Gerente Responsável: Fulano de Tal Principais stakeholders: presidência dos Correios (sponsor), Conselho de Administração dos Correios, gerente do projeto, equipe de desenvolvimento do projeto, fornecedores, clientes. Premissas:

a) O gerente terá prioridade na alocação de recursos humanos. b) Haverá disponibilidade de recursos humanos. c) Serão considerados os seguintes tipos de documentos: contas, cartas, faturas,

telegramas e propagandas. Restrições:

a) Orçamento limitado a R$ 1.000.000,00. b) Prazo limitado a 6 meses.

Exclusões:

a) Não é responsabilidade do projeto fazer a distribuição dos cartazes para as agências.


69

2) WBS

ATIVIDADE 5 1) Estrutura da Equipe do Projeto:

2) Perfis e Responsabilidades: Gerente de Projetos: Desempenhará as funções relativas à gerência do projeto, sendo responsável pela elaboração dos planos, acompanhamento e controle da execução dos mesmos. Deve ter experiência de gerência em projetos anteriores, ser capaz de trabalhar em equipe, ter conhecimento do domínio da aplicação e ter bom relacionamento com a alta gerência da empresa. Analista de Sistemas: Desempenhará as funções relativas a análise/projeto e coordenará as atividades relacionadas ao desenvolvimento do sistema. Também será responsável pelo treinamento dos usuários no sistema. Deve ter experiência de análise/projeto em projetos anteriores, ser capaz de trabalhar em equipe, ter conhecimento e prática nos

Projeto Correspondência Eletrônica

Sistema de Informação Capacitação Tecnologias Gerência do Projeto Implantação

Plano do Projeto

Relatórios de Acompanhamento

Dados e Lições Aprendidas

Tecnologias necessárias

Contratos com

Fornecedores

Requisitos

Projeto

Código

Relatórios de Testes

Material Didático

Espaço

Físico

Treinamento

Sistema instalado

Divulgação

Registro de Homologação

Comunicado no site

Folder

Gerente do Projeto

Analista de Sistemas

Programador1 Tester Programador2

Analista de TI

Analista de Marketing


70

conceitos da Orientação a Objetos e sua representação pelos diagramas da UML e da utilização das ferramentas CASE Rational Rose ou JUDE. Programador (1 e 2): Desempenhará as funções relativas à codificação, teses e instalação do sistema. Deve ter experiência de programação em projetos anteriores, ser capaz de trabalhar em equipe, ter conhecimento e prática nos conceitos da Orientação a Objetos e sua representação pelos diagramas da UML, bem como dominar programação JAVA e banco de dados Oracle. Tester: Desempenhará as funções relativas ao planejamento e execução dos testes do sistema. Deve ter experiência de testes em projetos anteriores, ser capaz de trabalhar em equipe, ter conhecimento do domínio e principais conceitos da aplicação. Analista de TI: Desempenhará as funções relativas à identificação das necessidades tecnológicas do projeto, bem como realizará a interface com os fornecedores. Deve ter experiência como analista de TI em projetos anteriores, ter conhecimento e experiência com tecnologias atuais bem como de seus potenciais fornecedores. Analista de Marketing: Desempenhará as funções relativas à divulgação do serviço. Deve ter experiência anterior em marketing e conhecer os padrões de marketing dos Correios. ATIVIDADE 7 Cronograma:

Id Atividade Predecessora(s) Duração Data Início Data Fim Recurso(s)

1 Elaborar Plano do Projeto 16 horas 01/10/2014 02/10/2014 Gerente

Tecnologias

2 Especificar tecnologias necessárias 1 8 03/10/2014 03/10/2014 Analista de TI 3 Contactar fornecedores 2 ... ...

4 Selecionar fornecedor ...

5 Assinar contrato

6 Receber tecnologias solicitadas Sistema de Informação

Análise

7 Realizar Levantamento de Requisitos

8 Elaborar Especificação de Requisitos

9 Avaliar Especificação de Requisitos Projeto

10 Elaborar Projeto de Arquitetura

11 Avaliar Projeto de Arquitetura

12 Elaborar Projeto de Interface

13 Avaliar Projeto de Interface 14 Elaborar Projeto de Banco de Dados

15 Avaliar Projeto de Banco de Dados

Códificação

16 Implementar unidades do sistema Testes

17 Elaborar Planos de Testes

18 Executar Testes de Unidade

Executar Testes de Sistema

Capacitação 19 Elaborar material didático

20 Alocar espaço físico

21 Realizar treinamento

Implantação

22 Realizar instalação do sistema 23 Obter homologação do sistema

Divulgação

24 Divulgar disponibilidade do serviço via site dos Correios

25 Divulgar disponibilidade do serviço via folders 26 Registrar encerramento do Projeto


71

ATIVIDADE 9 Planilha de Custos: Tipo de Recursos: Recursos Humanos

Recurso Quantidade Valor unitário Horas Valor Total

Gerente 1 60,00 ... ...

Analista de Sistemas 1 40,00 ... ...

Programador 2 30,00 ... ...

Tester 1 30,00 ... ...

Analista de TI 1 40,00 ... ...

Analista de Marketing 1 40,00 ... ...

Total com Recursos Humanos ...

Tipo de Recursos: Hardware

Recurso Quantidade Valor unitário Compra/uso Valor Total

Computador 16 2000,00 Compra 32000,00

Impressora laser 8 1500,00 Compra 12000,00

... ... ... ... ...

Total com Hardware: ...

Tipo de Recursos: Software

Recurso Quantidade Valor unitário Compra/uso Valor Total

Rational Rose 2 0,00 Uso 0

MS Project 1 0,00 Uso 0

... ... ... ... ...

Total com Software: ...

Despesas

Despesa Quantidade Valor unitário Frequência Valor Total

Encargos Sociais ... ... ... ...

... ... ... ... ...

Total com despesas:

Total Geral ...

ATIVIDADE 11

1) Identificação de Riscos Risco 1: Atraso pelos fornecedores. Categoria: Tempo. Contexto: Há atraso na entrega dos produtos solicitados aos fornecedores. Risco 2: Rotatividades na equipe. Categoria: Pessoal. Contexto: Durante o desenvolvimento do projeto há troca dos membros da equipe. 2) Priorização

Riscos Probabilidade Impacto Peso Prioridade Risco 1 Moderada Alto 5 1 Risco 2 Baixa Alto 4 2

Graduação:

Nível Peso Muito baixo 0

Baixo 1 Moderado 2

Alto 3

Verificar no

cronograma


72

Muito Alto 4 Peso (risco) = peso (probabilidade) + peso (impacto)

3) Plano das respostas (Plano de Contingência e Plano de Mitigação) Risco 1: Atraso pelos fornecedores. Plano de Mitigação: Incluir entre os critérios de seleção “assiduidade na entrega” e incluir no contrato cláusula inferindo multa em caso de atrasos. Plano de Contingência: Trocar de fornecedor, se ainda for possível, e/ou replanejar as dependências entre as atividades, buscando antecipar atividades para compensar o atraso na entrega. Risco 2: Rotatividades na equipe. Plano de Mitigação: Obter e formalizar comprometimento dos membros da equipe com o projeto e estabelecer premiação ao final do mesmo. Plano de Contingência: Realizar substituição monitorada pelo membro da equipe que será desligado. ATIVIDADE 13

1) Padrões de Qualidade a) Processo de desenvolvimento em conformidade com a ISO 9000:2000. b) Conformidade com os padrões de interface dos demais sistemas utilizados nos

Correios. 2) Marcos de Controle

a) Avaliação da Especificação de Requisitos b) Testes de Sistema c) Instalação

Em cada marco de controle o gerente irá analisar a qualidade dos itens produzidos e o desempenho do projeto até o momento. Além disso, será realizada uma auditoria de qualidade pelo gerente de qualidade de produto e processo do Departamento de Tecnologia de Informação dos Correios, que adotará o procedimento de Garantia da Qualidade consolidado no referido departamento. Nota: Vale ressaltar que, além dos marcos de controle, são necessários momentos de análise intermediários (pontos de controle) a fim de evitar que um acompanhamento e verificação do andamento do projeto sejam realizados em um espaço de tempo relativamente grande. Nos pontos de controle, devem-se realizar ações para verificar a qualidade dos itens produzidos e analisar o progresso do projeto (desempenho). ATIVIDADE 15 Alguns documentos utilizados no projeto:

a) Documento: Pauta de Reunião Descrição: documento utilizado para dar conhecimento dos tópicos que serão tratados em uma reunião aos participantes. Quando é elaborado: Até 24 horas antes de uma reunião. Elaborado por: Gerente ou líder do projeto. Acessado por: Todos os membros que participarão da reunião. Mídia: documento enviado em anexo a um email.


73

Formato:

b) Documento: Ata de Reunião Descrição: documento utilizado para registrar as decisões tomadas em uma reunião. Quando é elaborado: Até 24 horas depois de uma reunião. Elaborado por: Gerente ou líder do projeto. Acessado por: Todos os membros que participaram da reunião. Mídia: documento enviado em anexo a um email exigindo email de resposta indicando aceitação do conteúdo da ata. Formato:

Nota: outros documentos: relatório de acompanhamento do projeto, especificação de requisitos, project charter, contrato, etc.

ATIVIDADE 17 Necessidades de Aquisição:

a) 16 computadores. Especificação mínima:

Sistema Operacional: Windows 7® Home Basic Original em Português

Processador: Intel Core i5

Memória: Memória 4GB

Monitor: Monitor LCD 21 polegadas

Disco Rígido: 500 GB

Placa de Vídeo: Intel Graphics Media Accelerator 3100 Integrado

Placas de Som: Áudio 7.1 Canais Integrados

Suporte Pós Garantia: Mínimo de 1 ano de garantia padrão

Unidade de CD ou DVD: Gravador de CD/DVD

b) 8 impressoras HP LaserJet 2400. c) ...

ATA DE REUNIÃO Projeto: ______________________________________________________ Objetivo da reunião: _____________________________________________ Data: ____ / ___ / _____ Hora: ___: __ às __ : ___ Local:__________________ Participantes: _________________________________________________ ___________________________________________________________ Conteúdo:

(descrição das decisões tomadas na reunião).

PAUTA DE REUNIÃO Projeto: ______________________________________________________ Objetivo da reunião: _____________________________________________ Data: ____ / ___ / _____ Hora: ___: __ Local:__________________ Participantes: _________________________________________________ ___________________________________________________________ Tópicos a serem abordados: (lista de tópicos)

Gerência de Projetos - Notas de Aula (v5.0) – Monalessa Perini Barcellos _____________________________________________________________________________________________________________________________________________________

74

ANEXOS


75

Anexo 1

Métodos de Apoio à Elaboração de Cronogramas

Para elaborar o cronograma de um projeto, muitas são as técnicas que podem ser utilizadas. A seguir são apresentadas algumas das mais conhecidas.

1. Gráfico de Gantt

O Gráfico de Gantt representa o cronograma através de uma sequência de barras que

indicam a duração de cada atividade do projeto. O paralelismo entre as atividades é facilmente visualizado. À medida que as atividades são executadas, as barras correspondentes vão sendo coloridas.

A versão original do Gráfico de Gantt não traz as interdependências entre as atividades,

sendo esta sua maior limitação. Porém, versões ‘melhoradas’ desse método passaram a incluir a representação das interdependências. Exemplo: Gráfico de Gantt no MS Project. 2. PERT/CPM São técnicas que auxiliam a determinação de tempo total do projeto, as datas de início e fim, as folgas e o caminho crítico do projeto. Ambos são diagramas de redes, baseados na teoria dos grafos. PERT – Program Evaluation and Review Technique Utiliza uma metodologia estatística para realizar as estimativas de prazos das atividades. Surgiu na NASA em um projeto conhecido como programa Polaris. É uma técnica probabilística. Leva em consideração uma estimativa otimista (a), uma estimativa pessimista (b) e uma mais provável (m). Para calcular a estimativa utiliza-se:

e = (a + 4m + b)/6 Para calcular a variância:

s2 = [(b – a)/6]2

Para calcular o prazo mais provável para se concluir um projeto, basta somar as estimativas das atividades com a raiz quadrada da soma das variâncias: Tempo total = e + s2

Exemplo: Em um projeto:

Atividade

Estimativas (prazos em dias) Otimista Mais Provável Pessimista

A 14 27 47 B 41 60 89 C 39 44 48 D 29 37 42


76

Calcular a estimativa PERT de cada atividade e o tempo mais provável para que o projeto seja concluído. Solução: Utilizando-se e = (a + 4m + b)/6 temos:

Atividade

Estimativa PERT

A 28,2 B 61,7 C 43,8 D 36,5

Para calcular o tempo mais provável para concluir o projeto é preciso calcular a variância de cada atividade, através de s2 = [(b – a)/6]2 e utilizar a relação: Tempo total = e + s2

Sendo assim:

Atividade

Estimativa PERT

Variância

A 28,2 30,3 B 61,7 64,0 C 43,8 2,3 D 36,5 4,7

Tempo Total = 170,2 + 101,2 = 180,2 dias Representando as Atividades através de Diagramas Conhecendo as atividades, suas dependências e suas durações, torna-se possível representá-las através de diagramas que facilitam a visualização da rede de atividades do projeto. Existem várias maneiras de representar as atividades de um projeto, entre elas o diagrama de setas e o diagrama de blocos. Para isso, alguns conceitos são necessários: Datas: PDI – Primeira Data de Início: é a data em que a atividade pode começar se todas as antecessoras forem executadas no prazo. PDT – Primeira Data de Término: é a data de término de uma atividade que começa em PDI e termina no prazo. UDI – Última Data de Início: é a data limite de início de uma atividade para que ela possa ser concluída em UDT.


77

UDT – Última Data de Término: é a data limite de uma atividade ser concluída, sem atrasar o projeto. UDI – Última Data de Início: é a data limite de início de uma atividade para que ela possa ser concluída em UDT. Folgas: Folga livre: é a folga disponível em uma atividade, tal que não prejudica as PDI de suas predecessoras. É calculada por PDIsucessora – PDTatvidade – 1. Folga total: é o tempo que uma atividade pode atrasar sem comprometer o projeto como um todo. É calculada por UDI – PDI ou PDI – PDT .

Exemplo: Dadas as atividades de um projeto, como mostra a tabela abaixo, representar, utilizando o diagrama de setas, a rede das atividades, suas datas (considerando que o projeto terá início no dia 1º) e suas folgas.

Atividade

Dependências

Duração

A - 3 B - 3 C A 5 D A, B 5 E C, D 4

Solução:

As linhas pontilhadas são as chamadas ‘atividades fantasma’, pois apenas representam as dependências não visualizadas pelo sequenciamento normal de atividades.

Atv duração

PDI PDT

Notação:

3

1

B

3 6

D 5

5 9

C 5

4 8

4 5

E 4

10 13

1

2 A

3

3

3

1


78

Sendo assim:

Atividade Folga Livre Folga Total

A 0 0 B 1 1 C 1 1 D 0 0 E 0 0

Folga livre: Observe que B pode atrasar 1 dia sem comprometer o início de D e C pode

atrasar 1 dia sem comprometer o início de E. Folga total: Observe que B e C podem atrasar 1 dia sem comprometer a data final do

projeto. Analisando o diagrama de setas, percebe-se que para as atividades A, D e E , PDI = UDI

e PDT = UDT. Para C: PDI = 4, PDT = 8, UDI = 5 e UDT = 9. Para D: PDI = 1, PDT = 3, UDI = 2 e UDT = 4.

Obs.: Diagrama de Blocos É uma outra forma de representar a rede de atividades, porém, ao invés de nós e setas, utiliza-se blocos.

Comparação entre blocos e setas:

CPM – Critical Path Method Um caminho crítico é a sequência de atividades que tem menor folga total no projeto (não necessariamente zero). Ou seja, é o caminho (ou caminhos) cuja soma das durações das atividades constitui a duração do projeto. É o caminho de maior duração na rede. No exemplo apresentado anteriormente há dois caminhos críticos: ACE e BDE, ambos com duração = 12 e folga total = 1.

A

B C

Atv Duração

PDI PDT Atv Duração

PDI PDT

UDI UDT

ou

A

B C


79

Mecanismos para Redução nos prazos Muitas vezes é preciso reduzir o prazo de algumas atividades do projeto, ou por atraso em algumas atividades ou por outros fatores. Para isso, o gerente pode usar de dois artifícios:

1. Crashing: aumentar os recursos da atividade para terminá-la em menos tempo. Mas para isso é preciso estar atento ao impacto financeiro.

2. Fast Tracking: antecipar o início da atividade. Para isso é preciso ter cuidado para evitar retrabalho.

Para um melhor efeito, deve-se aplicar essas técnicas sobre as atividades do caminho

crítico, mas com cuidado para evitar, por exemplo, a mudança do caminho crítico sem muito resultado.

Referências:

FILHO, N. C., FÁVERO, J. S., Castro, J. E. E., Gerência de Projetos/Engenharia Simultânea, 1999, Editora Atlas – SP. PRADO, D., PERT/CPM, Série Gerência de Projetos, 1998, Volume 4, Editora DG, MG.


80

Anexo 2

Introdução à Análise de Valor Agregado – EVA

A análise de valor agregado é uma ferramenta que vem sendo bastante utilizada no gerenciamento de projetos. Nesse contexto, consiste em analisar o desempenho do projeto considerando três dimensões: tempo, custo e trabalho (escopo).

De forma resumida, significa analisar três curvas de desempenho. Uma curva representa o valor planejado para o projeto (dado pelo custo previsto para o projeto em sua baseline). Outra curva representa o valor planejado para o projeto para o trabalho a ser realizado até um dado momento (dado pelo custo previsto para o projeto até aquele momento). A terceira curva representa o valor real do trabalho realizado para o projeto naquele dado momento (dado pelo custo real do projeto naquele momento).

1. Variáveis para cálculo do Valor Agregado:

a) Custo Orçado do Trabalho Agendado (COTA) ou Planned Value (PV): é o custo planejado para o trabalho que deve ser realizado até um dado momento do projeto em sua baseline.

b) Custo Orçado do Trabalho Realizado (COTR) ou Earned Value (EV): é o custo planejado para o trabalho realizado até o momento.

c) Custo Real do Trabalho Realizado (CRTR) ou Actual Cost (AC): é o custo real para o trabalho realizado até o momento.

2. Principais Indicadores da Análise de Valor Agregado

a) Schedule Performance Index (SPI) ou Schedule Variance (SV): representa o percentual de cumprimento do cronograma. Um projeto que cumpre exatamente os prazos planejados apresenta um índice de 100%. Pode ser entendido como a velocidade relativa ao previsto que o projeto está sendo executado. Por isso, se este índice for menor que 100%, o projeto está atrasado. É dado por SPI = COTR/COTA (ou SPI = EV/PV).

b) Cost Performance Index (CPI) ou Cost Variance (CV): representa o percentual de cumprimento dos custos. É o custo total efetivo contra o previsto para o avanço atual do projeto. Um projeto que cumpre exatamente os custos planejados apresenta um índice de 100%. Um valor menor que este indica que o projeto está custando mais que o previsto. É dado por CPI = COTR/CRTR (ou CPI = EV/AC).


81

Gráfico 1: COTA x COTR x CRTR de um projeto de custo total orçado em R$ 50.000,00 (custo da baseline) e de duração total de 69 dias (duração da baseline). O projeto está atrasado (linha azul) e

acima do custo previsto (linha vermelha).

3. Previsões de Custos e Prazos usando EVA

a) Método Otimista

Segundo o método de previsão otimista, o desvio do cumprimento do cronograma ou de custos não constitui uma tendência de comportamento e pode ser considerada como um desvio de percurso que impactará nas novas tarefas apenas alterando a data de seu início. Em outras palavras, pela previsão otimista, todo o trabalho futuro do projeto será realizado de acordo com o ritmo previsto.

Assim, a previsão otimista é dada por:

Custo Previsto (Otimista) = (CRTR – COTR ) + custo da baseline

Duração Prevista (Otimista) = Atraso Atual + duração da baseline Atraso Atual = (1 – SPI) x tempo decorrido

Exemplo: Para o projeto hipotético representado no Gráfico 1, após decorridos 32 dias do projeto, COTR é R$ 12.800, COTA é R$ 21.000 e CRTR é R$ 29.500.

As previsões otimistas para esse projeto são:

Custo Previsto (Otimista) = (CRTR – COTR )+Custo da linha de Base = 29.500 – 12.800 + 50.000

Custo Previsto (Otimista) = R$ 66.700

Duração Prevista (Otimista) = Atraso Atual + duração da baseline Duração Prevista (Otimista) = ((1 – SPI) x Tempo decorrido) + 69

Duração Prevista (Otimista) = ((1 - 0,68) x 32) + 69 Duração Prevista (Otimista) = 10,24 + 69 = 79,24 dias

http://www.gerenciamentoeconomico.com.br/wp-content/eva1.bmp


82

b) Método Realista (ou do Valor Mais Provável)

Segundo o método realista o ritmo do projeto continuará com a mesma taxa de desvio que apresenta atualmente, ou seja, o SPI e CPI permanecerão constantes até o término do projeto.

Assim, a previsão realista é dada por:

Custo Previsto (Realista) = custo da baseline/CPI Duração Prevista (Realista) = duração da baseline/SPI

Exemplo: Para o projeto citado anteriormente, as previsões realistas são:

Custo Previsto (Realista) = custo da baseline/CPI Custo Previsto (Realista) = 50.000 / 0,42 = R$119.000

Duração Prevista (Realista) = duração da baseline/SPI

Duração Prevista (Realista) = 69 / 0,68 = 101 dias

c) Método Pessimista

É o método menos utilizado. Segundo ele, um projeto atrasado tende a custar ainda mais do que indica CPI, uma vez que são alocadas mais pessoas e/ou são realizadas horas extras para tentar recuperar o atraso e entregar o projeto no prazo previsto. Nesse caso, considera-se que o custo do projeto está relacionado ao Scheduled Cost Index (SCI), que é dado pela multiplicação do CPI pelo SPI.

Assim, a previsão pessimista é dada por:

Custo Previsto (Pessimista) = custo da baseline/(CPI x SPI)

Exemplo: Para o projeto citado anteriormente, a previsão de custo pessimista é:

Custo Previsto (Pessimista) = custo da baseline/(CPI x SPI) Custo Previsto (Pessimista) = 50.000 / (0,42 x 0,68) = R$175.000,00

Referência:

VARGAS, R. V., Valor Agregado em Projetos, 2005, 3ª Edição, Editora Brasport, Rio de

Janeiro – RJ.

Documents

Gerência de Projetos de Software - julionardi.scalfoni.com.br · Gerência de Projetos – Notas de Aula (v 5.0) – Monalessa Perini Barcellos 6 Escopo, tempo e custo formam o triângulo