Gerenciamento de Projetos: Planejamento, Processos e Áreas

Gerenciamento de Projetos
Versão 1.0.0

Sumário
I Sobre essa Apostila 3
II Informações Básicas 5
III GNU Free Documentation License 10
IV Gerenciamento de Projeto 19
1 Introdução 20
2 Plano de ensino 21
2.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Público Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 Bibliograﬁa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Projeto 24
3.1 Deﬁnição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Atuação do Gerente de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Planejamento de um Projeto 26
4.1 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Planejando um Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.1 WBS - Work Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.2 Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.3 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5 Processos 32
5.1 Processos de acordo com a Abordagem Tradicional . . . . . . . . . . . . . . . . . . 32
5.2 Grupo de Processos de Iniciação e Fechamento . . . . . . . . . . . . . . . . . . . . 33
5.2.1 Processos de Iniciação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.2 Processos de Fechamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1

CDTC Centro de Difusão de Tecnologia e Conhecimento Brasil/DF
5.3 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Processos de Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Processos de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6 Áreas de Conhecimento 37
6.1 Gerência da Integração do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2 Gerência do Escopo do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3 Gerência do Tempo de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4 Gerência do Custo do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.5 Gerência da Qualidade do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.6 Gerência dos Recursos Humanos do Projeto . . . . . . . . . . . . . . . . . . . . . . 41
6.7 Gerência das Comunicações do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.8 Gerência dos Riscos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.9 Gerência das Aquisições do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2

Conteúdo
O conteúdo dessa apostila é fruto da compilação de diversos materiais livres publicados na in-
ternet, disponíveis em diversos sites ou originalmente produzido no CDTC (http://www.cdtc.org.br.)
O formato original deste material bem como sua atualização está disponível dentro da licença
GNU Free Documentation License, cujo teor integral encontra-se aqui reproduzido na seção de
mesmo nome, tendo inclusive uma versão traduzida (não oﬁcial).
A revisão e alteração vem sendo realizada pelo CDTC (suporte@cdtc.org.br) desde outubro
de 2006. Críticas e sugestões construtivas serão bem-vindas a qualquer hora.
Autores
A autoria deste é de responsabilidade de Daniel Henrique da Silva (daniel@cdtc.org.br) .
O texto original faz parte do projeto Centro de Difusão de Tecnologia e Conhecimento que
vêm sendo realizado pelo ITI (Instituto Nacional de Tecnologia da Informação) em conjunto com
outros parceiros institucionais, e com as universidades federais brasileiras que tem produzido e
utilizado Software Livre apoiando inclusive a comunidade Free Software junto a outras entidades
no país.
Informações adicionais podem ser obtidas através do email ouvidoria@cdtc.org.br, ou da
home page da entidade, através da URL http://www.cdtc.org.br.
Garantias
O material contido nesta apostila é isento de garantias e o seu uso é de inteira responsabi-
lidade do usuário/leitor. Os autores, bem como o ITI e seus parceiros, não se responsabilizam
direta ou indiretamente por qualquer prejuízo oriundo da utilização do material aqui contido.
Licença
Copyright ©2006, Instituto Nacional de Tecnologia da Informação (cdtc@iti.gov.br) .
Permission is granted to copy, distribute and/or modify this document under the terms
of the GNU Free Documentation License, Version 1.1 or any later version published by
the Free Software Foundation; with the Invariant Chapter being SOBRE ESSA APOS-
TILA. A copy of the license is included in the section entitled GNU Free Documentation
License.
4

Parte II
Informações Básicas
5

Sobre o CDTC
Objetivo Geral
O Projeto CDTC visa a promoção e o desenvolvimento de ações que incentivem a dissemina-
ção de soluções que utilizem padrões abertos e não proprietários de tecnologia, em proveito do
desenvolvimento social, cultural, político, tecnológico e econômico da sociedade brasileira.
Objetivo Específico
Auxiliar o Governo Federal na implantação do plano nacional de software não-proprietário e
de código fonte aberto, identificando e mobilizando grupos de formadores de opinião dentre os
servidores públicos e agentes políticos da União Federal, estimulando e incentivando o mercado
nacional a adotar novos modelos de negócio da tecnologia da informação e de novos negócios
de comunicação com base em software não-proprietário e de código fonte aberto, oferecendo
treinamento específico para técnicos, profissionais de suporte e funcionários públicos usuários,
criando grupos de funcionários públicos que irão treinar outros funcionários públicos e atuar como
incentivadores e defensores dos produtos de software não proprietários e código fonte aberto, ofe-
recendo conteúdo técnico on-line para serviços de suporte, ferramentas para desenvolvimento de
produtos de software não proprietários e do seu código fonte livre, articulando redes de terceiros
(dentro e fora do governo) fornecedoras de educação, pesquisa, desenvolvimento e teste de pro-
dutos de software livre.
Guia do aluno
Neste guia, você terá reunidas uma série de informações importantes para que você comece
seu curso. São elas:
• Licenças para cópia de material disponível;
• Os 10 mandamentos do aluno de Educação a Distância;
• Como participar dos foruns e da wikipédia;
• Primeiros passos.
É muito importante que você entre em contato com TODAS estas informações, seguindo o
roteiro acima.
Licença
Copyright ©2006, Instituto Nacional de Tecnologia da Informação (cdtc@iti.gov.br).
6

É dada permissão para copiar, distribuir e/ou modiﬁcar este documento sob os termos
da Licença de Documentação Livre GNU, Versão 1.1 ou qualquer versão posterior
públicada pela Free Software Foundation; com o Capitulo Invariante SOBRE ESSA
APOSTILA. Uma cópia da licença está inclusa na seção entitulada "Licença de Docu-
mentação Livre GNU".
Os 10 mandamentos do aluno de educação online
• 1. Acesso à Internet: ter endereço eletrônico, um provedor e um equipamento adequado é
pré-requisito para a participação nos cursos a distância;
• 2. Habilidade e disposição para operar programas: ter conhecimentos básicos de Informá-
tica é necessário para poder executar as tarefas;
• 3. Vontade para aprender colaborativamente: interagir, ser participativo no ensino a distân-
cia conta muitos pontos, pois irá colaborar para o processo ensino-aprendizagem pessoal,
dos colegas e dos professores;
• 4. Comportamentos compatíveis com a etiqueta: mostrar-se interessado em conhecer seus
colegas de turma respeitando-os e se fazendo ser respeitado pelos mesmos;
• 5. Organização pessoal: planejar e organizar tudo é fundamental para facilitar a sua revisão
e a sua recuperação de materiais;
• 6. Vontade para realizar as atividades no tempo correto: anotar todas as suas obrigações e
realizá-las em tempo real;
• 7. Curiosidade e abertura para inovações: aceitar novas idéias e inovar sempre;
• 8. Flexibilidade e adaptação: requisitos necessário à mudança tecnológica, aprendizagens
e descobertas;
• 9. Objetividade em sua comunicação: comunicar-se de forma clara, breve e transparente é
ponto - chave na comunicação pela Internet;
• 10. Responsabilidade: ser responsável por seu próprio aprendizado. O ambiente virtual não
controla a sua dedicação, mas reﬂete os resultados do seu esforço e da sua colaboração.
Como participar dos fóruns e Wikipédia
Você tem um problema e precisa de ajuda?
Podemos te ajudar de 2 formas:
A primeira é o uso dos fóruns de notícias e de dúvidas gerais que se distinguem pelo uso:
. O fórum de notícias tem por objetivo disponibilizar um meio de acesso rápido a informações
que sejam pertinentes ao curso (avisos, notícias). As mensagens postadas nele são enviadas a
7

todos participantes. Assim, se o monitor ou algum outro participante tiver uma informação que
interesse ao grupo, favor postá-la aqui.
Porém, se o que você deseja é resolver alguma dúvida ou discutir algum tópico específico do
curso. É recomendado que você faça uso do Fórum de dúvidas gerais que lhe dá recursos mais
efetivos para esta prática.
. O fórum de dúvidas gerais tem por objetivo disponibilizar um meio fácil, rápido e interativo
para solucionar suas dúvidas e trocar experiências. As mensagens postadas nele são enviadas
a todos participantes do curso. Assim, fica muito mais fácil obter respostas, já que todos podem
ajudar.
Se você receber uma mensagem com algum tópico que saiba responder, não se preocupe com a
formalização ou a gramática. Responda! E não se esqueça de que antes de abrir um novo tópico
é recomendável ver se a sua pergunta já foi feita por outro participante.
A segunda forma se dá pelas Wikis:
. Uma wiki é uma página web que pode ser editada colaborativamente, ou seja, qualquer par-
ticipante pode inserir, editar, apagar textos. As versões antigas vão sendo arquivadas e podem
ser recuperadas a qualquer momento que um dos participantes o desejar. Assim, ela oferece um
ótimo suporte a processos de aprendizagem colaborativa. A maior wiki na web é o site "Wikipé-
dia", uma experiência grandiosa de construção de uma enciclopédia de forma colaborativa, por
pessoas de todas as partes do mundo. Acesse-a em português pelos links:
• Página principal da Wiki - http://pt.wikipedia.org/wiki/
Agradecemos antecipadamente a sua colaboração com a aprendizagem do grupo!
Primeiros Passos
Para uma melhor aprendizagem é recomendável que você siga os seguintes passos:
• Ler o Plano de Ensino e entender a que seu curso se dispõe a ensinar;
• Ler a Ambientação do Moodle para aprender a navegar neste ambiente e se utilizar das
ferramentas básicas do mesmo;
• Entrar nas lições seguindo a seqüência descrita no Plano de Ensino;
• Qualquer dúvida, reporte ao Fórum de Dúvidas Gerais.
Perfil do Tutor
Segue-se uma descrição do tutor ideal, baseada no feedback de alunos e de tutores.
O tutor ideal é um modelo de excelência: é consistente, justo e profissional nos respectivos
valores e atitudes, incentiva mas é honesto, imparcial, amável, positivo, respeitador, aceita as
idéias dos estudantes, é paciente, pessoal, tolerante, apreciativo, compreensivo e pronto a ajudar.
8

A classificação por um tutor desta natureza proporciona o melhor feedback possível, é crucial, e,
para a maior parte dos alunos, constitui o ponto central do processo de aprendizagem.’ Este tutor
ou instrutor:
• fornece explicações claras acerca do que ele espera e do estilo de classificação que irá
utilizar;
• gosta que lhe façam perguntas adicionais;
• identifica as nossas falhas, mas corrige-as amavelmente’, diz um estudante, ’e explica por-
que motivo a classificação foi ou não foi atribuída’;
• tece comentários completos e construtivos, mas de forma agradável (em contraste com um
reparo de um estudante: ’os comentários deixam-nos com uma sensação de crítica, de
ameaça e de nervossismo’)
• dá uma ajuda complementar para encorajar um estudante em dificuldade;
• esclarece pontos que não foram entendidos, ou corretamente aprendidos anteriormente;
• ajuda o estudante a alcançar os seus objetivos;
• é flexível quando necessário;
• mostra um interesse genuíno em motivar os alunos (mesmo os principiantes e, por isso,
talvez numa fase menos interessante para o tutor);
• escreve todas as correções de forma legível e com um nível de pormenorização adequado;
• acima de tudo, devolve os trabalhos rapidamente;
9

Parte III
GNU Free Documentation License
10

(Traduzido pelo João S. O. Bueno através do CIPSGA em 2001)
Esta é uma tradução não oficial da Licença de Documentação Livre GNU em Português Brasi-
leiro. Ela não é publicada pela Free Software Foundation, e não se aplica legalmente a distribuição
de textos que usem a GFDL - apenas o texto original em Inglês da GNU FDL faz isso. Entretanto,
nós esperamos que esta tradução ajude falantes de português a entenderem melhor a GFDL.
This is an unofficial translation of the GNU General Documentation License into Brazilian Por-
tuguese. It was not published by the Free Software Foundation, and does not legally state the
distribution terms for software that uses the GFDL–only the original English text of the GFDL does
that. However, we hope that this translation will help Portuguese speakers understand the GFDL
better.
Licença de Documentação Livre GNU Versão 1.1, Março de 2000
Copyright (C) 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
É permitido a qualquer um copiar e distribuir cópias exatas deste documento de licença, mas
não é permitido alterá-lo.
INTRODUÇÃO
O propósito desta Licença é deixar um manual, livro-texto ou outro documento escrito "livre"no
sentido de liberdade: assegurar a qualquer um a efetiva liberdade de copiá-lo ou redistribui-lo,
com ou sem modificações, comercialmente ou não. Secundariamente, esta Licença mantém
para o autor e editor uma forma de ter crédito por seu trabalho, sem ser considerado responsável
pelas modificações feitas por terceiros.
Esta Licença é um tipo de "copyleft"("direitos revertidos"), o que significa que derivações do
documento precisam ser livres no mesmo sentido. Ela complementa a GNU Licença Pública Ge-
ral (GNU GPL), que é um copyleft para software livre.
Nós fizemos esta Licença para que seja usada em manuais de software livre, por que software
livre precisa de documentação livre: um programa livre deve ser acompanhado de manuais que
provenham as mesmas liberdades que o software possui. Mas esta Licença não está restrita a
manuais de software; ela pode ser usada para qualquer trabalho em texto, independentemente
do assunto ou se ele é publicado como um livro impresso. Nós recomendamos esta Licença prin-
cipalmente para trabalhos cujo propósito seja de introdução ou referência.
APLICABILIDADE E DEFINIÇÕES
Esta Licença se aplica a qualquer manual ou outro texto que contenha uma nota colocada pelo
detentor dos direitos autorais dizendo que ele pode ser distribuído sob os termos desta Licença.
O "Documento"abaixo se refere a qualquer manual ou texto. Qualquer pessoa do público é um
11

licenciado e é referida como "você".
Uma "Versão Modificada"do Documento se refere a qualquer trabalho contendo o documento
ou uma parte dele, quer copiada exatamente, quer com modificações e/ou traduzida em outra
língua.
Uma "Seção Secundária"é um apêndice ou uma seção inicial do Documento que trata ex-
clusivamente da relação dos editores ou dos autores do Documento com o assunto geral do
Documento (ou assuntos relacionados) e não contém nada que poderia ser incluído diretamente
nesse assunto geral (Por exemplo, se o Documento é em parte um livro texto de matemática, a
Seção Secundária pode não explicar nada de matemática).
Essa relação poderia ser uma questão de ligação histórica com o assunto, ou matérias relaci-
onadas, ou de posições legais, comerciais, filosóficas, éticas ou políticas relacionadas ao mesmo.
As "Seções Invariantes"são certas Seções Secundárias cujos títulos são designados, como
sendo de Seções Invariantes, na nota que diz que o Documento é publicado sob esta Licença.
Os "Textos de Capa"são certos trechos curtos de texto que são listados, como Textos de Capa
Frontal ou Textos da Quarta Capa, na nota que diz que o texto é publicado sob esta Licença.
Uma cópia "Transparente"do Documento significa uma cópia que pode ser lida automatica-
mente, representada num formato cuja especificação esteja disponível ao público geral, cujos
conteúdos possam ser vistos e editados diretamente e sem mecanismos especiais com editores
de texto genéricos ou (para imagens compostas de pixels) programas de pintura genéricos ou
(para desenhos) por algum editor de desenhos grandemente difundido, e que seja passível de
servir como entrada a formatadores de texto ou para tradução automática para uma variedade
de formatos que sirvam de entrada para formatadores de texto. Uma cópia feita em um formato
de arquivo outrossim Transparente cuja constituição tenha sido projetada para atrapalhar ou de-
sencorajar modificações subsequentes pelos leitores não é Transparente. Uma cópia que não é
"Transparente"é chamada de "Opaca".
Exemplos de formatos que podem ser usados para cópias Transparentes incluem ASCII sim-
ples sem marcações, formato de entrada do Texinfo, formato de entrada do LaTex, SGML ou XML
usando uma DTD disponibilizada publicamente, e HTML simples, compatível com os padrões, e
projetado para ser modificado por pessoas. Formatos opacos incluem PostScript, PDF, formatos
proprietários que podem ser lidos e editados apenas com processadores de texto proprietários,
SGML ou XML para os quais a DTD e/ou ferramentas de processamento e edição não estejam
disponíveis para o público, e HTML gerado automaticamente por alguns editores de texto com
finalidade apenas de saída.
A "Página do Título"significa, para um livro impresso, a página do título propriamente dita,
mais quaisquer páginas subsequentes quantas forem necessárias para conter, de forma legível,
o material que esta Licença requer que apareça na página do título. Para trabalhos que não
tenham uma página do título, "Página do Título"significa o texto próximo da aparição mais proe-
minente do título do trabalho, precedendo o início do corpo do texto.
12

FAZENDO CÓPIAS EXATAS
Você pode copiar e distribuir o Documento em qualquer meio, de forma comercial ou não
comercial, desde que esta Licença, as notas de copyright, e a nota de licença dizendo que esta
Licença se aplica ao documento estejam reproduzidas em todas as cópias, e que você não acres-
cente nenhuma outra condição, quaisquer que sejam, às desta Licença.
Você não pode usar medidas técnicas para obstruir ou controlar a leitura ou confecção de
cópias subsequentes das cópias que você fizer ou distribuir. Entretanto, você pode aceitar com-
pensação em troca de cópias. Se você distribuir uma quantidade grande o suficiente de cópias,
você também precisa respeitar as condições da seção 3.
Você também pode emprestar cópias, sob as mesmas condições colocadas acima, e também
pode exibir cópias publicamente.
FAZENDO CÓPIAS EM QUANTIDADE
Se você publicar cópias do Documento em número maior que 100, e a nota de licença do
Documento obrigar Textos de Capa, você precisará incluir as cópias em capas que tragam, clara
e legivelmente, todos esses Textos de Capa: Textos de Capa da Frente na capa da frente, e
Textos da Quarta Capa na capa de trás. Ambas as capas também precisam identificar clara e
legivelmente você como o editor dessas cópias. A capa da frente precisa apresentar o título com-
pleto com todas as palavras do título igualmente proeminentes e visíveis. Você pode adicionar
outros materiais às capas. Fazer cópias com modificações limitadas às capas, tanto quanto estas
preservem o título do documento e satisfaçam a essas condições, pode ser tratado como cópia
exata em outros aspectos.
Se os textos requeridos em qualquer das capas for muito volumoso para caber de forma
legível, você deve colocar os primeiros (tantos quantos couberem de forma razoável) na capa
verdadeira, e continuar os outros nas páginas adjacentes.
Se você publicar ou distribuir cópias Opacas do Documento em número maior que 100, você
precisa ou incluir uma cópia Transparente que possa ser lida automaticamente com cada cópia
Opaca, ou informar, em ou com, cada cópia Opaca a localização de uma cópia Transparente
completa do Documento acessível publicamente em uma rede de computadores, à qual o público
usuário de redes tenha acesso a download gratuito e anônimo utilizando padrões públicos de
protocolos de rede. Se você utilizar o segundo método, você precisará tomar cuidados razoavel-
mente prudentes, quando iniciar a distribuição de cópias Opacas em quantidade, para assegurar
que esta cópia Transparente vai permanecer acessível desta forma na localização especificada
por pelo menos um ano depois da última vez em que você distribuir uma cópia Opaca (direta-
mente ou através de seus agentes ou distribuidores) daquela edição para o público.
É pedido, mas não é obrigatório, que você contate os autores do Documento bem antes de
redistribuir qualquer grande número de cópias, para lhes dar uma oportunidade de prover você
com uma versão atualizada do Documento.
13

MODIFICAÇÕES
Você pode copiar e distribuir uma Versão Modificada do Documento sob as condições das se-
ções 2 e 3 acima, desde que você publique a Versão Modificada estritamente sob esta Licença,
com a Versão Modificada tomando o papel do Documento, de forma a licenciar a distribuição
e modificação da Versão Modificada para quem quer que possua uma cópia da mesma. Além
disso, você precisa fazer o seguinte na versão modificada:
A. Usar na Página de Título (e nas capas, se houver alguma) um título distinto daquele do Do-
cumento, e daqueles de versões anteriores (que deveriam, se houvesse algum, estarem listados
na seção "Histórico do Documento"). Você pode usar o mesmo título de uma versão anterior se
o editor original daquela versão lhe der permissão;
B. Listar na Página de Título, como autores, uma ou mais das pessoas ou entidades responsá-
veis pela autoria das modificações na Versão Modificada, conjuntamente com pelo menos cinco
dos autores principais do Documento (todos os seus autores principais, se ele tiver menos que
cinco);
C. Colocar na Página de Título o nome do editor da Versão Modificada, como o editor;
D. Preservar todas as notas de copyright do Documento;
E. Adicionar uma nota de copyright apropriada para suas próprias modificações adjacente às
outras notas de copyright;
F. Incluir, imediatamente depois das notas de copyright, uma nota de licença dando ao público
o direito de usar a Versão Modificada sob os termos desta Licença, na forma mostrada no tópico
abaixo;
G. Preservar nessa nota de licença as listas completas das Seções Invariantes e os Textos de
Capa requeridos dados na nota de licença do Documento;
H. Incluir uma cópia inalterada desta Licença;
I. Preservar a seção entitulada "Histórico", e seu título, e adicionar à mesma um item dizendo
pelo menos o título, ano, novos autores e editor da Versão Modificada como dados na Página de
Título. Se não houver uma sessão denominada "Histórico"no Documento, criar uma dizendo o
título, ano, autores, e editor do Documento como dados em sua Página de Título, então adicionar
um item descrevendo a Versão Modificada, tal como descrito na sentença anterior;
J. Preservar o endereço de rede, se algum, dado no Documento para acesso público a uma
cópia Transparente do Documento, e da mesma forma, as localizações de rede dadas no Docu-
mento para as versões anteriores em que ele foi baseado. Elas podem ser colocadas na seção
"Histórico". Você pode omitir uma localização na rede para um trabalho que tenha sido publicado
pelo menos quatro anos antes do Documento, ou se o editor original da versão a que ela se refira
der sua permissão;
K. Em qualquer seção entitulada "Agradecimentos"ou "Dedicatórias", preservar o título da
14

seção e preservar a seção em toda substância e fim de cada um dos agradecimentos de contri-
buidores e/ou dedicatórias dados;
L. Preservar todas as Seções Invariantes do Documento, inalteradas em seus textos ou em
seus títulos. Números de seção ou equivalentes não são considerados parte dos títulos da seção;
M. Apagar qualquer seção entitulada "Endossos". Tal sessão não pode ser incluída na Versão
Modificada;
N. Não reentitular qualquer seção existente com o título "Endossos"ou com qualquer outro
título dado a uma Seção Invariante.
Se a Versão Modificada incluir novas seções iniciais ou apêndices que se qualifiquem como
Seções Secundárias e não contenham nenhum material copiado do Documento, você pode optar
por designar alguma ou todas aquelas seções como invariantes. Para fazer isso, adicione seus
títulos à lista de Seções Invariantes na nota de licença da Versão Modificada. Esses títulos preci-
sam ser diferentes de qualquer outro título de seção.
Você pode adicionar uma seção entitulada "Endossos", desde que ela não contenha qual-
quer coisa além de endossos da sua Versão Modificada por várias pessoas ou entidades - por
exemplo, declarações de revisores ou de que o texto foi aprovado por uma organização como a
definição oficial de um padrão.
Você pode adicionar uma passagem de até cinco palavras como um Texto de Capa da Frente
, e uma passagem de até 25 palavras como um Texto de Quarta Capa, ao final da lista de Textos
de Capa na Versão Modificada. Somente uma passagem de Texto da Capa da Frente e uma de
Texto da Quarta Capa podem ser adicionados por (ou por acordos feitos por) qualquer entidade.
Se o Documento já incluir um texto de capa para a mesma capa, adicionado previamente por
você ou por acordo feito com alguma entidade para a qual você esteja agindo, você não pode
adicionar um outro; mas você pode trocar o antigo, com permissão explícita do editor anterior que
adicionou a passagem antiga.
O(s) autor(es) e editor(es) do Documento não dão permissão por esta Licença para que seus
nomes sejam usados para publicidade ou para assegurar ou implicar endossamento de qualquer
Versão Modificada.
COMBINANDO DOCUMENTOS
Você pode combinar o Documento com outros documentos publicados sob esta Licença, sob
os termos definidos na seção 4 acima para versões modificadas, desde que você inclua na com-
binação todas as Seções Invariantes de todos os documentos originais, sem modificações, e liste
todas elas como Seções Invariantes de seu trabalho combinado em sua nota de licença.
O trabalho combinado precisa conter apenas uma cópia desta Licença, e Seções Invariantes
Idênticas com multiplas ocorrências podem ser substituídas por apenas uma cópia. Se houver
múltiplas Seções Invariantes com o mesmo nome mas com conteúdos distintos, faça o título de
15

cada seção único adicionando ao final do mesmo, em parênteses, o nome do autor ou editor
origianl daquela seção, se for conhecido, ou um número que seja único. Faça o mesmo ajuste
nos títulos de seção na lista de Seções Invariantes nota de licença do trabalho combinado.
Na combinação, você precisa combinar quaisquer seções entituladas "Histórico"dos diver-
sos documentos originais, formando uma seção entitulada "Histórico"; da mesma forma combine
quaisquer seções entituladas "Agradecimentos", ou "Dedicatórias". Você precisa apagar todas as
seções entituladas como "Endosso".
COLETÂNEAS DE DOCUMENTOS
Você pode fazer uma coletânea consitindo do Documento e outros documentos publicados
sob esta Licença, e substituir as cópias individuais desta Licença nos vários documentos com
uma única cópia incluida na coletânea, desde que você siga as regras desta Licença para cópia
exata de cada um dos Documentos em todos os outros aspectos.
Você pode extrair um único documento de tal coletânea, e distribuí-lo individualmente sob
esta Licença, desde que você insira uma cópia desta Licença no documento extraído, e siga esta
Licença em todos os outros aspectos relacionados à cópia exata daquele documento.
AGREGAÇÃO COM TRABALHOS INDEPENDENTES
Uma compilação do Documento ou derivados dele com outros trabalhos ou documentos se-
parados e independentes, em um volume ou mídia de distribuição, não conta como uma Ver-
são Modificada do Documento, desde que nenhum copyright de compilação seja reclamado pela
compilação. Tal compilação é chamada um "agregado", e esta Licença não se aplica aos outros
trabalhos auto-contidos compilados junto com o Documento, só por conta de terem sido assim
compilados, e eles não são trabalhos derivados do Documento.
Se o requerido para o Texto de Capa na seção 3 for aplicável a essas cópias do Documento,
então, se o Documento constituir menos de um quarto de todo o agregado, os Textos de Capa
do Documento podem ser colocados em capas adjacentes ao Documento dentro do agregado.
Senão eles precisarão aparecer nas capas de todo o agregado.
TRADUÇÃO
Tradução é considerada como um tipo de modificação, então você pode distribuir traduções
do Documento sob os termos da seção 4. A substituição de Seções Invariantes por traduções
requer uma permissão especial dos detentores do copyright das mesmas, mas você pode incluir
traduções de algumas ou de todas as Seções Invariantes em adição às versões orignais dessas
Seções Invariantes. Você pode incluir uma tradução desta Licença desde que você também in-
clua a versão original em Inglês desta Licença. No caso de discordância entre a tradução e a
16

versão original em Inglês desta Licença, a versão original em Inglês prevalecerá.
TÉRMINO
Você não pode copiar, modificar, sublicenciar, ou distribuir o Documento exceto como expres-
samente especificado sob esta Licença. Qualquer outra tentativa de copiar, modificar, sublicen-
ciar, ou distribuir o Documento é nula, e resultará automaticamente no término de seus direitos
sob esta Licença. Entretanto, terceiros que tenham recebido cópias, ou direitos de você sob esta
Licença não terão suas licenças terminadas, tanto quanto esses terceiros permaneçam em total
acordo com esta Licença.
REVISÕES FUTURAS DESTA LICENÇA
A Free Software Foundation pode publicar novas versões revisadas da Licença de Documen-
tação Livre GNU de tempos em tempos. Tais novas versões serão similares em espirito à versão
presente, mas podem diferir em detalhes ao abordarem novos porblemas e preocupações. Veja
http://www.gnu.org/copyleft/.
A cada versão da Licença é dado um número de versão distinto. Se o Documento especificar
que uma versão particular desta Licença "ou qualquer versão posterior"se aplica ao mesmo, você
tem a opção de seguir os termos e condições daquela versão específica, ou de qualquer versão
posterior que tenha sido publicada (não como rascunho) pela Free Software Foundation. Se o
Documento não especificar um número de Versão desta Licença, você pode escolher qualquer
versão já publicada (não como rascunho) pela Free Software Foundation.
ADENDO: Como usar esta Licença para seus documentos
Para usar esta Licença num documento que você escreveu, inclua uma cópia desta Licença
no documento e ponha as seguintes notas de copyright e licenças logo após a página de título:
Copyright (c) ANO SEU NOME.
É dada permissão para copiar, distribuir e/ou modificar este documento sob os termos da Licença
de Documentação Livre GNU, Versão 1.1 ou qualquer versão posterior publicada pela Free Soft-
ware Foundation; com as Seções Invariantes sendo LISTE SEUS TÍTULOS, com os Textos da
Capa da Frente sendo LISTE, e com os Textos da Quarta-Capa sendo LISTE. Uma cópia da li-
cença está inclusa na seção entitulada "Licença de Documentação Livre GNU".
Se você não tiver nenhuma Seção Invariante, escreva "sem Seções Invariantes"ao invés de
dizer quais são invariantes. Se você não tiver Textos de Capa da Frente, escreva "sem Textos de
Capa da Frente"ao invés de "com os Textos de Capa da Frente sendo LISTE"; o mesmo para os
Textos da Quarta Capa.
Se o seu documento contiver exemplos não triviais de código de programas, nós recomenda-
mos a publicação desses exemplos em paralelo sob a sua escolha de licença de software livre,
17

tal como a GNU General Public License, para permitir o seu uso em software livre.
18

Parte IV
Gerenciamento de Projeto
19

Capítulo 1
Introdução
Tudo hoje em dia tem que ser feito com muito planejamento, com uma boa supervisão no
decorrer do processo e com limites orçamentários bem estabelecidos. Isso é Gerenciar um Pro-
jeto. O Gerenciamento de Projeto vem desde a parte de assinatura do contrato para realização
da atividade até a entrega do resultado esperado. Nesse curso abordaremos um pouco de cada
fase para que o aluno entenda melhor e veja com qual parte se identiﬁca melhor.
20

Capítulo 2
Plano de ensino
2.1 Objetivo
Passar ao usuário a idéia do que é o projeto e do seu gerenciamento como um todo.
2.2 Público Alvo
Usuários que tenham interesse em se aperfeiçoar na área de projetos.
2.3 Pré-requisitos
Os usuários deverão ser, necessariamente, funcionários públicos e ter vontade de colocar em
prática o que aprendem em curso no seu dia-a-dia.
2.4 Descrição
O curso será realizado na modalidade Educação a Distância e utilizará a Plataforma Moodle
como ferramenta de aprendizagem. O curso tem duração de uma semana e possui um conjunto
de atividades (lições, fóruns, glossários, questionários e outros) que deverão ser executadas de
acordo com as instruções fornecidas. O material didático está disponível on-line de acordo com
as datas pré-estabelecidas em cada tópico.
Todo o material está no formato de lições, e estará disponível ao longo do curso. As lições
poderão ser acessadas quantas vezes forem necessárias. Aconselhamos a leitura de "Ambien-
tação do Moodle", para que você conheça o produto de Ensino a Distância, evitando diﬁculdades
advindas do "desconhecimento"sobre o mesmo.
Ao ﬁnal de cada semana do curso será disponibilizada a prova referente ao módulo estudado
anteriormente que também conterá perguntas sobre os textos indicados. Utilize o material de
cada semana e os exemplos disponibilizados para se preparar para prova.
Os instrutores estarão a sua disposição ao longo de todo curso. Qualquer dúvida deve ser
disponibilizada no fórum ou enviada por e-mail. Diariamente os monitores darão respostas e
esclarecimentos.
21

2.5 Metodologia
O curso está dividido da seguinte maneira:
• Lição 1 - Projeto
• Lição 2 - Planejamento de um Projeto
• Lição 3 - Processos
• Lição 4 - Áreas de Conhecimento
• Avaliação Final
As lições contêm o conteúdo principal. Elas poderão ser acessadas quantas vezes forem neces-
sárias, desde que esteja dentro da semana programada. Ao final de uma lição, você receberá
uma nota de acordo com o seu desempenho. Responda com atenção às perguntas de cada lição,
pois elas serão consideradas na sua nota final. Caso sua nota numa determinada lição for menor
do que 6.0, sugerimos que você faça novamente esta lição.
Ao final do curso será disponibilizada a avaliação referente a este. Tanto as notas das lições
quanto a da avaliação serão consideradas para a nota final. Todos os módulos ficarão visíveis
para que possam ser consultados durante a avaliação final.
Aconselhamos a leitura da "Ambientação do Moodle"para que você conheça a plataforma de En-
sino a Distância, evitando dificuldades advindas do "desconhecimento"sobre a mesma.
Os instrutores estarão a sua disposição ao longo de todo curso. Qualquer dúvida deverá ser
enviada no fórum. Diariamente os monitores darão respostas e esclarecimentos.
2.6 Programa
O curso de Gerenciamento de Projetos oferecerá o seguinte conteúdo:
• Idéia sobre projeto e seu gerenciamento;
• Área de Conhecimento e suas características;
2.7 Avaliação
Toda a avaliação será feita on-line.
Aspectos a serem considerados na avaliação:
• Iniciativa e autonomia no processo de aprendizagem e de produção de conhecimento;
• Capacidade de pesquisa e abordagem criativa na solução dos problemas apresentados.
Instrumentos de avaliação:
• Participação ativa nas atividades programadas.
• Avaliação ao final do curso.
22

• O participante fará várias avaliações referente ao conteúdo do curso. Para a aprovação e
obtenção do certificado o participante deverá obter nota final maior ou igual a 6.0 de acordo
com a fórmula abaixo:
• Nota Final = ((ML x 7) + (AF x 3)) / 10 = Média aritmética das lições
• AF = Avaliações
2.8 Bibliografia
• Sobre Gerência de Projeto e Gerências: http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_projetos
• Sobre Planejamento de Projeto: http://pt.wikipedia.org/wiki/Planejamento_de_projeto
• Sobre PMI: http://pt.wikipedia.org/wiki/pmi e http://www.pmi.org
• Sobre PMBOK: http://pt.wikipedia.org/wiki/PMBOK
• Sobre Processos: http://pt.wikipedia.org/wiki/Processos_da_ger%C3%AAncia_de_projetos
23

Capítulo 3
Projeto
Nesta lição, será mostrada a definição de Projeto, alguns tipos, e como o gerente de um
projeto deve atuar na elaboração e execução deste.
3.1 Definição
Projeto é um esforço temporário que tem início e fim bem definidos com o objetivo de criar
um serviço ou produto único que não foi criado ou desenvolvido anteriormente. Apesar de vários
projetos novos se parecerem com projetos anteriores, cada projeto tem sua singularidade, suas
diferenças com relação aos outros projetos, mesmo que uma pequena diferença.
A presença de semelhanças com outros projetos não tira a singularidade deste mesmo, senão
haveria uma certa limitação quanto ao número de projetos a serem desenvolvidos, o que não é
verdade.
Um projeto pode ter como objetivo vários produtos, desde um projeto para o desenvolvimento
de um software até um projeto para a implantação de um serviço de lavagem de carros. Todo
projeto é feito para manter uma melhor organização e um melhor planejamento para que seja
evitado imprevistos, na medida do possível, e o uso de mais capital do que o esperado.
Existem diversos tipos de projetos. Alguns deles são:
• Desenvolvimento, atualização ou manutenção de um novo software;
• Construção de uma casa, prédio ou outra obra;
• Prestação de algum tipo de serviço;
• Produção de documentos;
• Pesquisas e trabalhos.
Antes de um projeto existir sempre tem uma demanda. Nada é feito sem um propósito, por
isso, para um projeto ser pedido pelo cliente, este tem de precisar do resultado do projeto.
Falando na área de desenvolvimento de software o projeto seria a parte de projetar, ou mais
especificamente, de conceber algo desde o pedido pelo cliente até a implantação do produto.
24

3.2 Atuação do Gerente de Projeto
A atuação do Gerente de Projetos é essencial para o bom andamento do projeto, tanto fi-
nanceiramente como funcionalmente. O gerente fazendo um bom planejamento consegue evitar,
ou pelo menos minimizar, surpresas no decorrer do projeto, fazendo com que os custos sejam
diminuídos e o contrato seja cumprido à risca, evitando possíveis multas contratuais.
O Gerente de Projetos deve planejar e administrar tudo em relação ao projeto, desde a equipe
escolhida até o prazo final para a entrega do produto. Ele deve ser o tipo de pessoa que ad-
ministra muito bem a relação inter-pessoal, pois será a sua maior tarefa, administrar pessoas e
conseguir que elas cumpram prazos mesmo com as eventuais dificuldades do decorrer do desen-
volvimento do projeto.
Não podemos afirmar que o Gerente de Projetos é o melhor da equipe pois ele normalmente
não sabe de tudo com especificialidade, mas ele tem que saber um pouco de tudo, afinal de
contas ele é o responsável pela coordenação do projeto e tem que saber discutir sobre todos os
assuntos com as pessoas responsáveis por cada área.
O Gerente de Projetos deve coordenar o andamento do projeto adotando padrões, escolhendo
pessoal, administrando recursos e tempo. Além disso, o Gerente tem que estar sempre atento
a tudo que envolver o projeto, desde as mudanças necessárias, a política e os interesses dos
stakeholders. O Gerente trata de toda a parte administrativa do projeto além de ser o responsável
por qualquer problema que possa haver no futuro.
25

Capítulo 4
Planejamento de um Projeto
Nesta lição, mostraremos o que é um planejamento, suas etapas, algumas formas de planeja-
mento e algumas ferramentas e técnicas utilizadas no gerenciamento de um projeto. Isso tudo é
muito importante, pois, conhecendo esses detalhes, podemos evitar imprevistos na execução de
um projeto.
4.1 Planejamento
Planejamento signiﬁca determinar os objetivos ou metas de um empreendimento, como tam-
bém da coordenação de meios e recursos para atingí-los. Dentro da gestão de projetos, planeja-
mento é o processo usado para calcular o tempo e os custos de um projeto.
Dentre muitos objetivos, o resultado do planejamento serve para saber se o projeto é viável,
para determinar os prazos que serão dados e, principalmente, para o gerente do projeto poder
acompanhar os progressos da equipe e saber se estão dentro do esperado.
O planejamento de um projeto não pode se preocupar apenas com a entrega do resultado,
tem que se preocupar com todo o ciclo de vida. Desde a liberação para iniciar o projeto até a
manutenção e o tempo depois que entregar o produto, como vemos a seguir no esquema:
1. Coleta de Requisitos;
2. Análise de como fazer o que foi pedido;
3. Desenvolvimento;
4. Os testes;
5. Entrega e aceitação do resultado;
6. Implantação;
7. Manutenção.
Os tipos de ciclo de vidas existentes variam e esse apresentado acima é apenas um modelo
de como pode ser um. Os tipos mais conhecidos de abordagem de ciclo de vida são:
26

• Top-down (de cima para baixo) - Método conhecido como Cascata. É baseado na decom-
posição funcional, inicia-se com a análise do sistema e prossegue pelas fases de requisitos,
projeto, implementação e testes.
• Bottom-up (de baixo para cima) - As atividades do cronograma são decompostas em partes
mais detalhadas.
• Prototipação - é a construção preeliminar do projeto para simular a aparência e as funcio-
nalidades, como o nome já diz.
Muitos pensam que o planejamento do projeto é feito antes de se iniciar o projeto e pronto não
se pensa mais nisso, mas isso está completamente errado. O planejamento pode ser adaptado
no decorrer do projeto por mudanças, pode ser atualizado pelo progresso da equipe e por diver-
sos outros fatores. O gerente de projeto é o principal responsável pelo planejamento do projeto e
essa é uma tarefa que ele leva no decorrer de todo o projeto.
O planejamento pode seguir diversos modelos já existentes, mas cada um desses modelos
tem de se adaptar ao projeto em si, por isso dificilmente consegue-se copiar um planejamento
de um projeto anterior por mais parecido que seja. Em lições seguintes apresentaremos alguns
tipos de modelos de planejamento de projeto.
4.2 Planejando um Projeto
As Etapas de um Planejamento:
1. Determinar quais são as condições exatas para que o resultado produzido seja o esperado,
isto é, saber exatamente o que fazer para que o projeto esteja exatamente de acordo com
o seu escopo. Não adianta fazer cálculos de tempo e custo sem saber quais são os reais
objetivos do projeto.
2. Fazer uma relação entre trabalho e tempo para cada pessoa para saber quanto tempo vai
ser gasto em cada tarefa. Feito isso, verificar quais tarefas levarão muito tempo para serem
finalizadas. Separar essas tarefas em tarefas menores, criando assim uma WBS - Work
Breakdown Struture (Estrutura de Divisão do Trabalho).
3. Identificar os recursos necessários para cada tarefa do WBS, assim será possível verificar
qual será o custo de cada tarefa e conseqüentemente de todo o projeto. A essa estimativa
damos o nome de bottom-up.
4. Decidir se o projeto é viável (se vale a pena) e se é necessário modicar os objetivos finais
para diminuir custo, tempo ou o que desejar.
5. Construção e documentação das dependências entre tarefas (definição de quais tarefas
precisam do resultado de outra para serem iniciadas e etc.).
6. Calcular, através das dependências entre tarefas, o tempo mínimo para finalizar o projeto,
para isso usamos o caminho crítico.
7. Criar um cronograma do projeto de acordo com o que já foi definido.
8. Determinar os riscos do projeto e fazer as adaptações necessárias.
27

9. Iniciar a execução do projeto de acordo com o que foi definido no passos anteriores.
Esse é apenas um pequeno esboço de um planejamento de um projeto simples. Não que
plajenar um projeto maior seja totalmente diferente, pelo contrário. Um projeto grande contém
todo o planejamento de um projeto pequeno, o diferencial é o detalhamento dos processos, pois
os riscos, os gastos, o tempo e os demais detalhes são muito mais precisos e maiores.
4.3 Ferramentas
Abaixo vamos apresentar algumas ferramentas e técnicas usadas na gerência de projetos
(não só no planejamento, mas em todo o processo) que ajudam todos os componentes da equipe
e o projeto como um todo.
4.3.1 WBS - Work Breakdown Structure
No português, Estrutura Analítica de Projetos (EAP), é uma ferramenta de decomposição do
trabalho do projeto em partes manejáveis. Uma abordagem do tipo top-down, isso é, vai da ati-
vidade mais geral para mais especifica. O WBS organiza, define e graficamente mostra tanto o
produto a ser feito como o trabalho a ser realizado para obtê-lo. Por isso, a WBS é uma ferra-
menta muito usada para o planejamento do projeto.
De acordo com o PMBOK (Project Management Body of Knowledge), WBS é: "Um agrupa-
mento de elementos do projeto, orientados para resultados, que organiza e define o completo
escopo do projeto. Cada nível descente representa uma definição cada vez mais detalhada do
trabalho do projeto."
Com o EAT o projeto é subdividido, através da técnica de decomposição, em seus principais
componentes. É um instrumento amplamente utilizado e é muito recomendado pelo PMI (Project
Management Institute) como um dos instrumentos padrão na Gerência de Projeto. WBS serve
como base para formação das frentes de trabalho (equipes do projeto), alocação de recursos e
definição de custo e tempo dos pacotes de trabalho.
Passos para a construção de uma WBS:
1. Colocar no primeiro nível da WBS, nível 0, o nome do projeto.
2. Colocar no segundo nível as fases que estabelecem o ciclo de vida do projeto.
3. Acrescentar um elemento, no segundo nível, para conter os deliverables (subprodutos) ne-
cessários ao gerenciamento do projeto.
4. Identificar os subprodutos necessários para que seja alcançado o sucesso do projeto em
cada fase.
5. Para cada subproduto, verificar se as estimativas de custo e tempo, assim como a identi-
ficação de riscos, podem ser desenvolvidos neste nível de detalhe e se é possível atribuir
a responsabilidade para a execução do mesmo. Se a resposta for negativa, decompor o
28

elemento da WBS, subdividindo-o em componentes menores, mais manejáveis, até que os
subprodutos estejam definidos em detalhe suficiente para suportar o desenvolvimento dos
processos de gerenciamento do projeto (planejar, executar, controlar,encerrar).
6. Rever para que se possa refinar a WBS.
A WBS deve ser completa, organizada e pequena o suficiente para que o progresso possa
ser medido, mas não detalhada o suficiente para se tornar, ela mesma, um obstáculo para a rea-
lização do projeto.
Um projeto fictício para demonstrar o uso de uma WBS
Como exemplo, vamos utilizar uma produção de um determinado software chamado Inter-
comCQ.
1. Projeto IntercomCQ.
1.1 Definição;
1.1.1 Levantamento preliminar das necessidades;
1.1.2 Levantamento preliminar das possibilidades;
1.1.3 Project Charter.
1.2 Estudo de Viabilidade:
1.2.1 Relatório Técnico preliminar;
1.2.2 Medida dos impactos nos Negócios;
1.2.3 Avaliação do Custo;
1.2.4 Payback Period;
1.2.5 Relatório Consolidado;
1.2.6 Apresentação do Estudo;
1.2.7 Aprovação do Estudo.
1.3 Pesquisa:
1.3.1 Levantamento das detalhado das Tecnologias disponíveis para o projeto;
1.3.2 Relatório Consolidado;
1.3.3 Apresentação do Relatório;
1.3.4 Apresentação do Relatório;
1.4 Seleção:
1.4.1 Tecnologias Escolhidas;
1.4.2 Avaliação;
1.4.3 Resultado da Avaliação;
1.5 Gerenciamento do Projeto.
1.6 Contratação:
1.6.1 Redação Contrato;
1.6.2 Negociação Contrato;
1.6.3 Parecer Jurídico;
1.6.4 Assinatura do Contrato.
1.7 Preparação para Implantação:
1.7.1 Desenvolvimento / Customização;
1.7.2 Integração com tecnologias pré-existentes;
1.7.3 Migração do sistema antigo para o novo.
29

1.8 Implantação:
1.8.1 Instalação;
1.8.2 Teste;
1.8.3 Correções;
1.8.4 Treinamento.
1.9 Inicio das Operações:
1.9.1 Acompanhamento Inicial;
1.9.2 Correções.
4.3.2 Diagrama de Gantt
O diagrama de Gantt é uma estimativa gráfica usada para visualizar as etapas e os avanços
do projeto. O diagrama pode ser usado tanto para uma fase do projeto, como para um processo
ou até mesmo para todo o projeto em si. Abaixo podemos ver um exemplo simples:
Como se vê na imagem, o eixo horizontal marca o tempo decorrido do projeto, os objetos
azuis podem ser tanto fases, quanto processos ou tarefas. Podemos ver também que alguns
retângulos azuis coincidem o final com o início de outro.
4.3.3 Cronograma
O cronograma é algo bem simples, mas que é extremamente útil, para não dizer indispensá-
vel, para a elaboração de um projeto bem como de seu planejamento. No cronograma se define
o que e, principalmente, quando será feito. O cronograma é tanto uma ferramenta para estimar
prazos e conseqüentemente custos como uma ferramenta de gerenciamento no geral, pois o ge-
rente a utiliza para gerir os outros membros da equipe. Todos devem conhecer como é a estrutura
30

de um cronograma, pois é algo bem simples. Abaixo segue um exemplo de um cronograma de
projeto ﬁctício.
Além dessas ferramentas, diversas outras ajudam no gerenciamento de projetos.
31

Capítulo 5
Processos
Nesta lição, faremos uma descrição dos processos de um projeto de acordo com a Abordagem
Tradicional, sendo eles: Iniciação, Planejamento, Execução, Controle e Fechamento.
5.1 Processos de acordo com a Abordagem Tradicional
Costuma-se dividir um projeto em grupos de processos (pedaços) para ter uma melhor orga-
nização e visualização do andamento do projeto. Normalmente os grupos são chamados de:
• Iniciação;
• Planejamento;
• Execução;
• Controle;
• Fechamento.
Cada grupo de processo gera um tipo de resultado diferente e tanto se diferencia do outro
como está relacionado com o outro. Todo processo é uma parte do todo (o projeto) e tanto pode
ter seu tempo pequeno, como Iniciação, como também pode ser executado ao longo de todo o
projeto, como Controle.
Cada grupo de processos, assim como os processos em si, estão ligados pelos resultados,
pois um depende do resultado do outro para poder iniciar ou ter continuidade, exemplo:
O Controle de Cronograma, que faz parte dos Processos de Controle, precisa que seja feito
um Cronograma na parte de Planejamento de Cronograma para que ele, o Controle de Crono-
grama, sejá usado, o que é bastante óbvio.
Dentro dos grupos de processos, apresentados anteriormente, existem os básicos e os faci-
litadores. Os básicos são os que seguem uma ordem lógica, têm uma dependência com outros
processos, já os facilitadores tem essa ordem mais ﬂexível e são normalmente usados para aju-
dar nos processos básicos.
32

O gerente é o principal responsável pelo andamento do projeto, como já foi dito anteriormente,
mas não somente ele deve saber como anda o projeto em si. A participação de todos é essencial,
para isso, o gerente deve informar a todos como está o andamento do projeto, para que toda a
equipe e demais stakeholders sintam que estão a par de tudo. A comunicação do desempenho do
projeto é um dos principais elementos para que o gerenciamento do projetos seja bem sucedido.
Uma maneira bem interessante de fazer com que os clientes fiquem mais satisfeitos com o
projeto é envolvê-los no mesmo. Com isso, o cliente - que é a parte mais interessada- vai poder
ver o desenvolver do projeto em si e adequar melhor o projeto as suas necessidades e , con-
seqüentemente, ele verá que os requisitos estão de acordo ou não ao que está sendo produzido.
Pelos processos, podemor focar melhor cada parte do projeto e se preocupar com partes mais
bem definidas. Vamos detalhar melhor cada processo que citamos anteriormente.
5.2 Grupo de Processos de Iniciação e Fechamento
5.2.1 Processos de Iniciação
Como bem o nome diz, iniciação é o começo, a partida. É a parte em que se faz o pedido
do projeto em si e que ele é autorizado a ser feito. Trata-se mais da parte contratual do que de
desenvolvimento em si, mas ao mesmo tempo é uma das principais partes pois é ai que se trata
dos valores.
A iniciação não se trata apenas de começar o projeto ela pode se referir a uma fase ou
uma parte do projeto, como por exemplo iniciar o desenvolvimento do software ou então iniciar a
implantação ou a fase de testes. Em suma, iniciação trata-se de iniciar o projeto ou uma parte
dele. Dentre os processos de Iniciação, podemos citar:
• Desenvolver o termo de abertura;
• Desenvolver a declaração de escopo preliminar do projeto.
5.2.2 Processos de Fechamento
É a parte de finalização do projeto em si ou de uma fase do projeto. Pode ser caracterizada
pela aceitação do cliente ao verificar que o resultado está de acordo com o que ele pediu ou
então, pode ser caracterizada pela iniciação da fase final do projeto em si.
Esse grupo de processo, assim como a iniciação, pode ser ligado a todo o projeto como tam-
bém a uma fase dele. Esse é o grupo de processo que verifica se os resultados dos outros grupos
estão de acordo com o que foi definido para poder encerrar o projeto ou uma fase dele, feito isso,
ele aceita formalmente o resultado ou não. A finalização desse grupo de processos se caracteriza
pelo encerramento do contrato.
Existe uma pequena diferença entre encerrar o projeto e encerrar o contrato, que são dois
processos do grupo de Processos de Encerramento. O Encerramento do projeto se caracteriza
pelo fim das atividades de todos os grupos de processos para poder encerrar formalmente o
projeto ou uma fase dele, já o encerramento do contrato se caracteriza pela entrega do produto
ou resultado e pela liquidação de quaisquer pontos em aberto.
33

5.3 Planejamento
O planejamento é uma das partes mais cruciais do projeto, já que o andamento correto do
projeto depende de um bom e preciso planejamento para não haver surpresas e imprevistos fu-
turos, o que poderia acarretar em custos maiores ou até quebra de contrato por conta do não
cumprimento do prazo estipulado.
No Planejamento define-se o escopo do projeto, as atividades e seu seqüenciamento, o cro-
nograma com seus caminhos, o Plano do Projeto, o plano de riscos e a estimativa de custos.
Dentre os processos de Planejamento, podemos citar:
• Desenvolver o plano de gerenciamento do projeto - processo necessário para integrar todos
os outros processos do grupo;
• Planejamento do escopo - Criação do plano de gerenciamento de escopo;
• Definição do escopo - Processo para desenvolver a declaração detalhada do escopo;
• Criar EAP - Processo que subdivide o processo em partes para serem entregues;
• Definição da atividade - Processo para identificar as atividades que deverão ser efetuadas
para entregar cara parte do projeto;
• Seqüenciamento de atividades - Processo para identificar as tarefas e suas dependências
de acordo com o cronograma;
• Estimativa de recusos de atividade - Processo para identificar a quantidade de recursos que
serão gastos para cada atividade;
• Estimativa de duração da atividade - Processo para identificar o tempo que será gasto para
cada atividade;
• Desenvolvimento do cronograma - Processo para analisar restrições do cronograma, dura-
ção de atividades e seqüenciamento;
• Estimativa de custos - Processo para dar uma idéia dos custos necessários para terminar o
projeto;
• Planejamento de Qualidade - Processo para identificar os padrões de qualidades;
• Planejamento de recuros Humanos - Processo para delegar funções no projeto;
• Planejamento de comunicações - Processo para determinar as necessidades de informação
e comunicação dos stakeholders;
• Planejamento de gerenciamento de riscos - Processo para decidir como tratar o gerencia-
mento de riscos do projeto;
• Identificação de riscos - Processo para identificar os riscos que poderão vir a afetar futura-
mente o projeto;
• Planejar compras e aquisições - Processo para determinar o que e quando comprar;
• e etc.
34

Como se pode ver, o planejamento é o começo de um bom projeto. No planejamento a defini-
ção dos melhores caminhos, dos objetivos e das ferramentas a serem usadas é um ponto forte e
muito importante.
Quando estamos fazendo o planejamento de um software existem várias dependências, fases
que dependem de fases anteriores para o seu início ou a sua finalização, a isso damos o nome
de caminho crítico. Explicando mais explicitamente, de acordo com o Wikipédia:
"Caminho Crítico é um termo criado para designar um conjunto de tarefas vinculadas a uma
ou mais tarefas que não têm margem de atraso.
Matematicamente, sabemos que uma tarefa é crítica quando o tempo mais cedo da tarefa é
igual ao tempo mais tarde que a tarefa pode ter sem alterar a data final do projeto. O valor do
tempo mais cedo (Time Earlier) e do tempo mais tarde (Time Later) pode ser calculado através
do diagrama de Rede AON (Activity on nodes)."
fonte: http://pt.wikipedia.org/wiki/Caminho_cr%C3%ADtico
O caminho da parte de cima (P1->P2->P5->P7) é o caminho crítico
Quanto menos caminho crítico um projeto tiver, menor é o risco de ocorrerem atrasos. Na
figura acima, caso P3 ou P4 atrasem pouco, o projeto pode não atrasar. Já no caminho crítico,
caso uma fase atrase, o projeto conseqüentemente vai atrasar, pois o projeto depende do tempo
dele.
5.4 Processos de Execução
Os processo de execução são usados para finalizar o que foi definido no plano de gerenci-
amento do projeto. Esse grupo envolve a coordenação de pessoal e das tarefas realizadas por
eles, a integração, a implementação das mudanças e etc. A execução é grupo de processos
central do projeto.
Quase sempre ocorre mudanças no projeto em sua execução, e para que essas mudanças
sejam implementadas um novo planejamento tem de ser realizado. É na execução que temos o
maior gasto de todo o projeto.
Podemos destacar alguns processos desse grupo, como:
35

• Orientar e gerenciar a execução do projeto - Orientar as atividades para que seja executado
o trabalho que foi definido anteriormente no plano de gerenciamento de projeto;
• Realizar a garantia da qualidade - Aplicar as atividades de qualidade que foram plajenadas;
• Contratar ou mobilizar a equipe do projeto - Contratar pessoal para o projeto;
• Desenvolver a equipe do projeto - Processos para aprimorar a interação e as competências
dos membros do projeto;
• Distribuição das informações - Distribuir as informações para todas as partes interessadas
no projeto;
• Solicitar respostas de fornecedores - Obter informações a respeito dos possíveis fornece-
dores;
• Selecionar fornecedores - Filtrar as ofertas e escolher os fornecedores.
5.5 Processos de Controle
Como o nome já diz, é a parte de controle do projeto. É nela que se monitora o andamento
e mede-se o desempenho do projeto verificando se está dentro do esperado e informando para
que seja tomanda decisões acerca das respostas obtidas, para, caso necessário, sejam tomadas
atitudes para que algum problema seja solucionado.
É esse processo que tem a função de garantir que os objetivos ou resultados do projeto sejam
alcançados. Para isso, são usados vários recursos como gráficos, monitoramento de tempo de
tarefas, medição do progresso de tempos em tempos, de acordo com o tempo final ou a necessi-
dade, para que as ações necessárias sejam tomadas antes que problemas mais sérios ocorram
e prejudiquem o andamento e, conseqüentemente, o tempo do projeto.
Nesse processo podemos identificar:
• Controle do Cronograma - onde verifica-se se as tarefas e fases estão em dia, evitando
assim possíveis atrasos;
• Controle dos Custos - onde verifica-se se o projeto está de acordo com o orçamento estipu-
lado no planejamento;
• Controle de Qualidade - onde verifica-se se o projeto está seguindo o padrão estipulado
inicialmente;
• Controle de mudanças de escopo - Assim como o controle de qualidade, aqui identifica-se
se o padrão está seguindo o que foi pedido inicialmente e se as mudanças autorizadas
estão sendo feitas corretamentes;
• Relato de Desempenho - Um documento que descreve o andamento do projeto em si, em
sua fase de desenvolvimento, mais precisamente, e que dá conformidade, se for o caso, ou
relata erros antecipadamente para que sejam solucionados;
• e etc.
36

Capítulo 6
Áreas de Conhecimento
Nesta lição, descreveremos as diversas áreas de conhecimento participantes ao longo do
desenvolvimento de um projeto de acordo com o PMBOK.
6.1 Gerência da Integração do Projeto
A Gerência de Integração de Projeto é necessária para assegurar que os vários elementos do
projeto sejam adequadamente coordenados. A Gerência de Integração é responsável por:
• Identificar;
• Definir;
• Combinar;
• Unificar;
• Coordenar.
Os diversos processos e as atividades dentro dos grupos existentes na gerência de projeto.
É a Gerência de Integração que tem a função de amenizar possíveis problemas, e para isso, ela
deve tratá-los antes que se tornem algo maior.
A Gerência de Integração é responsável principalmente pela ligação entre os processos dos
grupos de processos, os quais são totalmente dependentes.
Funções da Gerência da Integração do Projeto, segundo o PMBOK:
• Desenvolver o termo de abertura do Projeto - Autorização formal para dar início ao projeto
em si;
• Desenvolver a declaração do escopo preeliminar do Projeto;
• Desenvolver o Plano de Gerenciamento do Projeto - Um plano que integre e coordene todos
os outros planos das outras gerências.
• Orientar e gerenciar a execução do projeto - Tentar manter o projeto no rumo da decla-
ração de escopo do projeto e de acordo com o plano de gerenciamento que foi definido
anteriormente;
37

• Monitorar e controlar o trabalho do projeto;
• Controle de Integração de Mudanças - Fazer uma revisão dos pedidos de mudanças feitos
e avaliar se são possíveis e necessárias;
• Encerrar o projeto - Fazer a finalização formal do projeto ou de uma de suas fases.
6.2 Gerência do Escopo do Projeto
A Gerência de Escopo, como bem o nome diz, é a Gerência que cuida da adequação do
projeto de acordo com o que foi pedido, e apenas ao que foi pedido. Ela serve como um ponto
de referência para dizer se o trabalho foi concluído (seja o trabalho todo ou apenas uma fase) de
acordo com o que foi pedido, se ainda falta algo para ser incluído ou ainda se tem algo a mais,
algo que não foi pedido.
A palavra escopo pode ser entendida como objetivo ou foco e a gerência de escopo como a
gerência de objetivo, ou seja, ela gerencia o objetivo em relação ao projeto para que tudo que foi
pedido seja desenvolvido e tudo que será desenvolvido seja o que foi pedido, apenas.
De acordo com o PMBOK, a Gerência do Escopo do Projeto é responsável pelo:
• Planejamento do Escopo - Criação do plano de gerenciamento do escopo do projeto para
documentar como o escopo do projeto será definido e controlado, além de definir e criar a
EAP do projeto;
• Definição do Escopo - Criação de um documento detalhado sobre o escopo do projeto para
que seja usado em futuras decisões acerca do projeto;
• Criar EAP - A criação da Estrutura Analítica do Projeto serve para dividir as entregas do pro-
jeto (ou partes dele) em projetos menores, facilitando assim o gerenciamento e verificação
do escopo;
• Verificação do Escopo - É apenas uma formalização (aceitação ou não) do que foi entregue.
É avaliar para saber se o que foi entregue está dentro do desejado ou não;
• Controle do Escopo - No decorrer do projeto às vezes são necessarias algumas mudanças,
e para isso é imprescindível o controle dessa mudanças para saber se elas são necessárias
mesmo e se há a possibilidade delas serem realizadas.
Esses processos podem ser usados uma ou até mais vezes no decorrer do processo ou em
fases. O gerenciamento do escopo do projeto precisa estar integrado aos outros processos para
que funcione corretamente e tenha como resultado final a entrega do escopo do produto correta-
mente.
Obs: Existe uma diferença entre escopo do projeto e escopo do produto:
- Escopo do Projeto é o projeto a ser realizado para entregar o produto especificado;
- Escopo do Produto são as caracteristicas que descrevem o produto em si.
38

6.3 Gerência do Tempo de Projeto
O principal objetivo da gerência do tempo de projeto é administrar o tempo e descrever os
processos requeridos para o término do projeto, garantindo que se cumpra os prazos definidos
em um cronograma de atividades criado pela gerência em questão.
Os principais processos desta gestão são:
• Definições das Atividades: identificação das atividades de acordo com o cronograma;
• Seqüenciar Atividades: identificação das dependências entre as atividades do cronograma
do projeto;
• Estimativa de Recursos de Atividade: estimativa das quantidades dos recursos requeridos
para cada atividade;
• Estimativa de Duração de Atividade: estimativa do tempo que será gasto para conclusão de
cada atividade individual presente no cronograma;
• Desenvolvimento do Cronograma: análise do seqüênciamento, da duração e das depen-
dências das atividades para criar o cronograma;
• Controle do Cronograma: controle das alterações efetuadas no cronograma.
Esses processos são totalmente ligados entre si e entre os outros processos do projeto, pois
são eles que controlam e determinam o tempo de todo o projeto ou de uma fase, de acordo com
as necessidades.
A gerência do tempo de projeto e a gerência do custo do projeto são as áreas de maior
exigência dentro de um projeto, pois são as mais vísiveis em sua gestão. Os processos da
gerência do tempo, descritos anteriormente, são documentados no plano de gerenciamento do
cronograma, e este pode tanto fazer parte do plano de gerenciamento de projeto, como pode ser
um plano auxiliar.
6.4 Gerência do Custo do Projeto
O objetivo da gerência do custo é conseguir fazer com que o projeto gere o maior lucro pos-
sível, e para isso ela tem de fazer com que o projeto gaste o mínimo possível e que esse mínimo
não seja alterado no decorrer do processo. O controle dos custos no decorrer do processo é a
parte mais difícil.
Os principais processos envolvidos são:
• Estimativa de custos: desenvolvimento de um plano com as estimativas de custo das ativi-
dades do projeto;
• Orçamentação: Estabelecer uma linha de base de custos do projeto de acordo com os
custos das atividades;
• Controle de custos: controlar os gastos do projeto para que não saia do que foi planejado
inicialmente.
39

Em projetos muito pequenos, a Orçamentação e a Estimativa de custos são tão próximas que
às vezes uma das duas é dispensada, pois o custo e o número de tarefas é muito pequeno.
O gerenciamento de custos do projeto deve considerar o efeito das decisões do projeto sobre
o custo de utilização, manutenção e suporte do produto e o serviço ou resultado do projeto, a isso
damos o nome de estimativa de custos do ciclo de vida, e normalmante, quando se economiza
em algo no projeto, como uma redução no suporte, os gastos são transferidos para o cliente, pois
ele que terá de arcar com isso. Essa técnica, juntamente com outras, pode ser usada para reduzir
o custo e o tempo de entrega do produto.
6.5 Gerência da Qualidade do Projeto
O objetivo mais importante dessa gerência é se certiﬁcar que o projeto seja feito de acordo
com a qualidade desejada, garantindo a satisfação do cliente e de suas necessidades.
Existem inúmeros tipos de abordagem de qualidade de projeto, as mais conhecidas são:
• ISO (International Organization Standardization);
• GQT (Gerenciamento de Qualidade Total);
• Seis Sigma;
• Análise de modos e efeitos de falhas;
• e etc.
As qualidades exigidas em um tipo de projeto diferem muito das de outros projetos. Por exem-
plo, não se pode querer que um projeto de engenharia civil tenha o mesmo padrão de qualidade
de um software. Por isso existem projetos que não aceitam erros.
O gerente de projeto e a sua equipe de gerenciamento são os responsáveis por determinar e
fornecer os níveis de qualidade do projeto e os níveis de exatidão e precisão são necessários.
O PMBOK subdivide o gerenciamento da qualidade em três processos:
• Planejamento da qualidade: Estipular os padrões de qualidades que serão usados no pro-
jeto e como serão usados;
• Garantia da qualidade: Aplicação das qualidades que foram plajenadas anteriormente;
• Controle da qualidade: Monitorar o decorrer do projeto para se certiﬁcar que a qualidade do
produto esteja dentro dos critérios que foram estipulados no planejamento.
Esses processos interagem e dependem entre si, pois o primeiro planeja, o segundo executa
e o terceiro controla os dois anteriores.
40

6.6 Gerência dos Recursos Humanos do Projeto
A Gerência de Recursos Humanos inclui os processos requeridos para possibilitar o uso mais
efetivos das pessoas envolvidas com o Projeto. A organização e o gerenciamento da equipe do
projeto é papel fundamental da Gerência de RH, como é conhecida.
Os processos da Gerência dos Recursos Humanos, de acordo com o PMBOK, são:
• Planejamento de recursos Humanos: Identificar as funções de cada membro da equipe no
projeto, para isso é criado um plano de gerenciamento de pessoal;
• Contratar ou mobilizar a equipe do projeto: Contratação de pessoal para o projeto;
• Desenvolver a equipe do projeto: Melhorar a comunicação e as competências dos membros
do projeto;
• Gerenciar a equipe do projeto: Acompanhamento do desempenho dos membros das equi-
pes e atitudes para melhorar o desempenho, caso seja necessário.
Para um melhor aproveitamento, os membros das equipes tem de receber um feedback, para
que eles possam saber como está o trabalho deles e como está o projeto em si. Usar os membros
das equipes para auxiliar na tomada de decisões também é uma grande arma incentivadora, pois
estimula a participar mais ativamente. Com isso, ele se sentirá mais participativo e fortalecerá o
seu compromisso com o projeto e poderá contribuir mais e melhor para o sucesso do mesmo.
6.7 Gerência das Comunicações do Projeto
Gerência de Comunicação é a parte que se encarrega por coletar, distribuir e armazenar as
informações acerca do projeto e suas fases de desenvolvimento. Essa gerência deve diminuir o
tempo e os caminhos usados para haver uma boa e efetiva comunicação entre os membros das
equipes, pois esse é um fator fundamental para o progresso das entregas do projeto.
De acordo com o PMBOK, esses são alguns processos da Gerência das Comunicações:
• Planejamento das comunicações: determinar até que ponto as informações vão ser divul-
gadas e para quem elas serão levadas;
• Distribuição das informações: distribuição da informação a todos do projeto;
• Relatório de desempenho: Coleta e distribuição a respeito do desempenho;
• Gerenciar as partes interessadas: gerenciamento das informações para satisfazer os sta-
keholders;
O objetivo é a realização de negociações que permitam diminuir os conflitos entre objetivos
e alternativas concorrentes, com a finalidade de atingir às necessidades e expectativas dos sta-
keholders.
41

6.8 Gerência dos Riscos do Projeto
A gerência de Riscos do Projeto não é responsável apenas em evitar os riscos, pois muitos
desses as vezes são impossíveis de serem evitados, ela é responsavel também por saber como
lidar com os riscos. A gerência tem que saber antecipadamente quais são os prováveis riscos
que o projeto corre e quais as soluções mais viáveis e possíveis para cada um desses riscos.
Ao se ouvir falar de risco todos pensam em algo negativo, algo que vá prejudicar o projeto
mas não é sempre assim. Existem riscos que podem vir a ajudar o projeto, como um exemplo
podemos citar a seguinte situação: A gerência de aquisições faz um pedido ao fornecedor e esse
pede o prazo de duas semanas para poder entregar, mas diz que pode ocorrer de conseguir
entregar antes do prazo, portanto esse é um risco que deve ser documentado, pois o prazo que
deve-se contar é o prazo estipulado em contrato, mas se o risco corrido (de chegar antes) se
concretizar, o projeto pode chegar a ser adiantado, o que é muito proveitoso.
Quase tudo que não é certo pode ser tratado como um risco. Desde um documento pedido e
que ainda não foi expedido até uma possível agressão ao meio ambiente nos casos de constru-
ção civil por exemplo.
Os Processos envolvidos na Gerência de Risco de acordo com o PMBOK:
• Planejamento do gerenciamento de riscos: é o planejamento de como tratar os possíveis
riscos do projeto e como executar as atividades relativas a estes;
• Identiﬁcação de riscos: determinar quais são os possíveis riscos que podem vir a afetar o
projeto;
• Análise qualitativa de riscos: depois de determinado quais são os riscos, separar quais
são os riscos que merecem prioridade de tratamento de acordo com sua probabilidade e
conseqüência para o projeto;
• Análise quantitativa de riscos: análise do possível efeito que os riscos podem trazer ao
projeto;
• Planejamento de respostas a riscos: determinar as respostas (antecipadas ou não) para
poder miniminizar os riscos ou seus efeitos;
• Monitoramento e controle de riscos: controle dos possíveis riscos e seus efeitos no decorrer
do projeto.
Em suma, a Gerência de Risco do Projeto trata-se da maximização dos resultados de eventos
positivos e minimização dos eventos negativos.
6.9 Gerência das Aquisições do Projeto
A Gerência de Aquisição é responsável pelos processos ligados à aquisição de produtos pro-
venientes de fora da equipe e que essa mesma não possa (ou não queira) produzir. Além disso,
cabe a essa gerência a administração dos contratos de compras, locação e contratação, (além
de outros) feito com fornecedores do projeto.
42

Os processos da Gerência de Aquisição do Projeto de acordo com a abordagem do PMBOK
são:
• Planejar compras e aquisições: determinar o que comprar e quando;
• Planejar contratações: saber de quais fornecedores comprar ou pelo menos cotar os preços;
• Solicitar respostas de fornecedores: cotação de preços junto aos prováveis fornecedores;
• Selecionar fornecedores: analisar as propostas recebidas dos fornecedores e negociar pre-
ços e contrato com eles;
• Administração de contrato: Gerenciamento dos fornecedores para saber qual está mais de
acordo com os objetivos do projeto;
• Encerramento de contrato: Finalizar os contratos e seus pontos pendentes. Seja o contrato
ﬁnal ou o contrato de apenas uma fase (uma entrega) apenas.
43

Gerenciamento de Projetos: Planejamento, Processos e Áreas

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Gerenciamento de Projetos: Planejamento, Processos e Áreas

Semelhante a Gerenciamento de Projetos: Planejamento, Processos e Áreas (20)

Mais de Tiago

Mais de Tiago (20)

Último

Último (20)

Gerenciamento de Projetos: Planejamento, Processos e Áreas