Gerenciamento de Projetos de TI

Gerenciamento
de Projetos
de TI
Rodrigo Alves Costa
A RNP Rede Nacional de Ensino

e Pesquisa qualificada como
uma Organizao Social (OS),
sendo ligada ao Ministrio da
Cincia, Tecnologia e Inovao
(MCTI)
responsvel
pelo
Programa Interministerial RNP,

que conta com a participao dos
ministrios da Educao (MEC), da
Sade (MS) e da Cultura (MinC).
Pioneira no acesso Internet no
Brasil, a RNP planeja e mantm a
rede Ip, a rede ptica nacional
acadmica de alto desempenho.
Com Pontos de Presena nas
27 unidades da federao, a rede
tem mais de 800 instituies
conectadas. So aproximadamente
3,5 milhes de usurios usufruindo
de uma infraestrutura de redes
avanadas para comunicao,
computao e experimentao,
que contribui para a integrao
entre o sistema de Cincia e
Tecnologia, Educao Superior,
Sade e Cultura.
Gerenciamento
de Projetos
de TI
Rodrigo Alves Costa
Gerenciamento
de Projetos
de TI
Rodrigo Alves Costa
Rio de Janeiro
Escola Superior de Redes
2016
Copyright 2016 Rede Nacional de Ensino e Pesquisa RNP

Rua Lauro Mller, 116 sala 1103
22290-906 Rio de Janeiro, RJ
Diretor Geral
Nelson Simes
Diretor de Servios e Solues
Jos Luiz Ribeiro Filho

Coordenador Nacional
Leandro Marcos Oliveira Guimares

Edio
Lincoln da Mata
Coordenador Acadmico da rea de Governana de TI
Edson Kowask Bezerra
Equipe ESR (em ordem alfabtica)
Adriana Pierro, Alynne Figueiredo, Celia Maciel, Derlina Miranda, Elimria Barbosa,
Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato ,
Renato Duarte e Yve Marcial.
Capa, projeto visual e diagramao
Tecnodesign
Verso
2.0.0
Este material didtico foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dvida com relao ao material ou seu uso seja enviado para a equipe de elaborao de
contedo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e
Pesquisa e os autores no assumem qualquer responsabilidade por eventuais danos ou perdas, a
pessoas ou bens, originados do uso deste material.
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.
Dados Internacionais de Catalogao na Publicao (CIP)
C838g
Costa, Rodrigo

Gerenciamento de Projetos de TI / Rodrigo Costa. 2 ed. rev. Rio de Janeiro: RNP/ESR, 2016.

224p.: il.; 28 cm.

ISBN 978-85-63630-02-5

1.Gerenciamento de projetos de tecnologia da informao. 2.Gerenciamento de projetos

Tecnologia da informao planejamento, gesto e controle. 3.PMBok.I. Ttulo.

CDD 658.4
Sumrio
A metodologia da ESRvii
Sobre o curso viii
A quem se destina ix
Convenes utilizadas neste livroix
Permisses de usox
Sobre os autoresx
1. Motivao
Foco do curso2
Organizao3
Ferramentas5
Recursos6
Abordagem7
Introduo ao Gerenciamento de Projetos de TI7
Objetivos7
Exerccios de nivelamento7
Introduo8
O que gerenciamento de projetos?9
Estgios do ciclo de gerenciamento de projetos10
Estgio de planejamento e escopo11
Execuo11
Por que o gerenciamento de projetos necessrio?12
Tamanho de projetos12
iii
Checklist de um projeto arruinado12

Principais fatores para o sucesso de um projeto13
Exerccio de fixao 1 Falhas de gerenciamento de projeto13
Exemplo de custo da falha14
Exerccio de fixao 2 Gerenciamento bem-sucedido de projetos14
2. Iniciao
Introduo16
Definio do escopo16
Identificando expectativas e necessidades dos stakeholders17
Identificando os stakeholders17
Papis comuns de stakeholders19
Definindo os requisitos dos stakeholders19
Mtodos para identificar requisitos20
Razes para requisitos inadequados20
Identificando consideraes21
Identificando requisitos de negcio21
Definio de necessidade de negcio22
Requisitos balanceados22
Exerccio de fixao 1 Determinando e refinando necessidades de negcio23
Motivaes informais de projeto24
Exerccio de fixao 2 Motivaes informais24
Conceito preliminar de projeto25
Realizando uma anlise de requisitos de sistema26
Reviso dos requisitos de negcio27
Regulamentaes da indstria e requisitos28
Critrios de sucesso29
Exerccio de fixao 3 Identificando e verificando requisitos de negcio 29
O patrocinador do projeto32
Criando um documento de escopo33
Componentes de um documento de escopo34
Um documento de escopo tipicamente define:34
iv
3. Planejamento
Introduo40
Planejamento40
Criando uma Estrutura Analtica do Projeto42
Desenvolvendo estimativas de esforo, tempo e custos48
Exerccio de fixao 1 Estimativas de esforo, tempo e custo54
4. Plano de gerenciamento do projeto

Criando um cronograma de projeto55
Importncia de um cronograma56
Componentes de um cronograma57
Variabilidade do Caminho Crtico63
Criando um oramento de projeto63
Contratos de fornecedores e critrios de performance67
Exerccio de fixao 1 Definindo contrataes junto a fornecedores 70
Criando um plano de gerenciamento de recursos71
Identificar o qu, quando e para quem73
Escolhendo entre mtodos formais e informais de comunicao74
Exerccio de fixao 2 Desenvolvendo um plano de comunicao 74
Criando um plano de gerenciamento da qualidade77
Qualidade de produto79
Exerccio de fixao 3 Desenvolvimento de mtricas de qualidade82
Criando um plano de gerenciamento do projeto83
Plano de gerenciamento do projeto84
5. Execuo, monitoramento e controle

Introduo88
Execuo, monitoramento e controle88
Monitoramento e controle do projeto89
Atividades de acompanhamento do projeto89
Gerenciando recursos92
Atrasos de cronograma92
Exerccio de fixao 1 Tentando resolver atrasos de cronograma93
Exerccio de fixao 2 Negociao de problemas por atrasos de cronograma 94
Exerccio de fixao 3 Aplicabilidade de mtodos de teste para um projeto
de desenvolvimento99
6. Encerramento
Introduo109
Encerramento do projeto110
Realizando uma reunio de aceitao com o cliente112
Conduzindo uma reviso de projeto113
Exerccio de fixao 1 Encerramento do projeto115
Identificando as lies aprendidas117
Compilando um relatrio de projeto118
vi

A Escola Superior de Redes (ESR) a unidade da Rede Nacional de Ensino e Pesquisa (RNP)
responsvel pela disseminao do conhecimento em Tecnologias da Informao e Comunicao (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competncias
em TIC para o corpo tcnico-administrativo das universidades federais, escolas tcnicas e
unidades federais de pesquisa. Sua misso fundamental realizar a capacitao tcnica do
corpo funcional das organizaes usurias da RNP, para o exerccio de competncias aplicveis ao uso eficaz e eficiente das TIC.
A ESR oferece dezenas de cursos distribudos nas reas temticas: Administrao e Projeto
de Redes, Administrao de Sistemas, Segurana, Mdias de Suporte Colaborao Digital e
Governana de TI.
A ESR tambm participa de diversos projetos de interesse pblico, como a elaborao e
execuo de planos de capacitao para formao de multiplicadores para projetos educacionais como: formao no uso da conferncia web para a Universidade Aberta do Brasil
(UAB), formao do suporte tcnico de laboratrios do Proinfo e criao de um conjunto de
cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).
A metodologia da ESR
A filosofia pedaggica e a metodologia que orientam os cursos da ESR so baseadas na
aprendizagem como construo do conhecimento por meio da resoluo de problemas tpicos da realidade do profissional em formao. Os resultados obtidos nos cursos de natureza
terico-prtica so otimizados, pois o instrutor, auxiliado pelo material didtico, atua no
apenas como expositor de conceitos e informaes, mas principalmente como orientador do
aluno na execuo de atividades contextualizadas nas situaes do cotidiano profissional.
A aprendizagem entendida como a resposta do aluno ao desafio de situaes-problema
semelhantes s encontradas na prtica profissional, que so superadas por meio de anlise,
sntese, julgamento, pensamento crtico e construo de hipteses para a resoluo do problema, em abordagem orientada ao desenvolvimento de competncias.
Dessa forma, o instrutor tem participao ativa e dialgica como orientador do aluno para as
atividades em laboratrio. At mesmo a apresentao da teoria no incio da sesso de aprendizagem no considerada uma simples exposio de conceitos e informaes. O instrutor
busca incentivar a participao dos alunos continuamente.
vii
As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das

atividades prticas tm formato presencial e essencialmente prtico, utilizando tcnicas de
estudo dirigido individual, trabalho em equipe e prticas orientadas para o contexto de atuao do futuro especialista que se pretende formar.
As sesses de aprendizagem desenvolvem-se em trs etapas, com predominncia de tempo
para as atividades prticas, conforme descrio a seguir:
Primeira etapa: apresentao da teoria e esclarecimento de dvidas (de 60 a 90 minutos).
O instrutor apresenta, de maneira sinttica, os conceitos tericos correspondentes ao tema
da sesso de aprendizagem, com auxlio de slides em formato PowerPoint. O instrutor
levanta questes sobre o contedo dos slides em vez de apenas apresent-los, convidando
a turma reflexo e participao. Isso evita que as apresentaes sejam montonas e que o
aluno se coloque em posio de passividade, o que reduziria a aprendizagem.
Segunda etapa: atividades prticas de aprendizagem (de 120 a 150 minutos).
Esta etapa a essncia dos cursos da ESR. A maioria das atividades dos cursos assncrona e
realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto
no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dvidas e
oferecer explicaes complementares.
Terceira etapa: discusso das atividades realizadas (30 minutos).
O instrutor comenta cada atividade, apresentando uma das solues possveis para resolv-la,
devendo ater-se quelas que geram maior dificuldade e polmica. Os alunos so convidados a
comentar as solues encontradas e o instrutor retoma tpicos que tenham gerado dvidas,
estimulando a participao dos alunos. O instrutor sempre estimula os alunos a encontrarem
solues alternativas s sugeridas por ele e pelos colegas e, caso existam, a coment-las.
Sobre o curso
O curso capacita na utilizao da tecnologia e das ferramentas necessrias para o planejamento, gesto e controle de projetos de TI, atendendo aos requisitos de uma formao slida e consistente, contemplada em diferentes frameworks de gerenciamento de
projetos. O conjunto de boas prticas oferecido ao aluno est contido no Project Management Body of Knowledge (PMBok) do Project Management Institute (PMI), sem no entanto
restringir-se a ele ou prender-se sua estrutura de processos e reas de conhecimento.
Ao final do curso, o aluno estar capacitado para entender as dimenses tcnicas e comportamentais do gerenciamento de projetos, tornando-o apto a utilizar conhecimentos
tcnicos, ferramentas e mtodos em apoio gesto, ao mesmo tempo em que o prepara
para compreender a importncia das habilidades e competncias relacionais e atitudinais
como meios necessrios para garantir que os projetos alcancem os seus objetivos.
Este prprio curso resultado de um projeto de desenvolvimento bem-sucedido e gerenciado com base no conjunto de boas prticas aqui recomendadas. uma demonstrao de
que o uso de prticas consolidadas de gerenciamento produz resultados mais desejveis
para o projeto, mais aderentes aos objetivos estabelecidos e mais eficazes para garantir a
satisfao dos clientes e usurios dos produtos, servios e solues gerados.
viii
A quem se destina
Gestores e tcnicos de TI que desejam atualizar os seus conhecimentos sobre gerenciamento
de projetos e sua aplicabilidade nas organizaes. Tambm integram o pblico-alvo do curso
diretores, gerentes, coordenadores e supervisores da rea deTI que desejam aperfeioar
suas habilidades de gerenciamento.
Convenes utilizadas neste livro

As seguintes convenes tipogrficas so usadas neste livro:
Itlico
Indica nomes de arquivos e referncias bibliogrficas relacionadas ao longo do texto.
Largura constante
Indica comandos e suas opes, variveis e atributos, contedo de arquivos e resultado da sada
de comandos. Comandos que sero digitados pelo usurio so grifados em negrito e possuem
o prefixo do ambiente em uso (no Linux normalmente # ou $, enquanto no Windows C:\).
Contedo de slide q
Indica o contedo dos slides referentes ao curso apresentados em sala de aula.
Smbolo w
Indica referncia complementar disponvel em site ou pgina na internet.
Smbolo d
Indica um documento como referncia complementar.
Smbolo v
Indica um vdeo como referncia complementar.
Smbolo s
Indica um arquivo de adio como referncia complementar.
Smbolo
Indica um aviso ou precauo a ser considerada.
Smbolo p
Indica questionamentos que estimulam a reflexo ou apresenta contedo de apoio ao
entendimento do tema em questo.
Smbolo l
Indica notas e informaes complementares como dicas, sugestes de leitura adicional ou
mesmo uma observao.
Permisses de uso
Todos os direitos reservados RNP.
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra.
Exemplo de citao: TORRES, Pedro et al. Administrao de Sistemas Linux: Redes e Segurana.
Rio de Janeiro: Escola Superior de Redes, RNP, 2013..
ix
Comentrios e perguntas
Para enviar comentrios e perguntas sobre esta publicao:
Escola Superior de Redes RNP
Endereo: Av. Lauro Mller 116 sala 1103 Botafogo
Rio de Janeiro RJ 22290-906
E-mail: info@esr.rnp.br
Sobre os autores
Rodrigo Alves Costa atualmente professor efetivo do curso de Cincias da Computao
da Universidade Estadual da Paraba e doutorando em Cincias da Computao na Universidade Federal de Pernambuco (UFPE). Possui mestrado em Cincias da Computao pela
UFPE (2010), MBA em Gerenciamento de Projetos pela Fundao Getlio Vargas (2007) e
graduao em Cincias da Computao pela UFPE (2005). certificado Project Management
Professional (PMP) pelo Project Management Institute (PMI) (2006). Tem vasta atuao profissional, destacando-se em funes como executivo de projetos, analista de sistemas, engenheiro de sistemas, de segurana e de software em empresas como IBM, Siemens, Motorola
e C.E.S.A.R. Tambm autor de livros na rea de administrao organizacional com foco
em projetos, entre os quais Gerenciamento de Projetos de TI, e colaborador de cursos de
gesto empresarial em tecnologias da informao e comunicao em diversas organizaes
e instituies de ensino, sendo um dos idealizadores do currculo de governana da Rede
Nacional de Pesquisa, vinculado ESR/RNP/CNPQ. Foi bolsista CNPQ durante o mestrado e
a graduao (PIBIC), e atualmente est vinculado aos diretrios de pesquisa da entidade, no
grupo de estudos em Segurana Computacional da UFPE. Pesquisador na rea de Cincia da
Computao, com nfase em segurana computacional e teoria da computao, e na rea de
Gerenciamento de Projetos, com nfase em gerenciamento de projetos virtuais e planejamento estratgico orientado por TIC. membro entusiasta do PMI, membro da Association
for Computing Machinery (ACM) e da Sociedade Brasileira de Computao (SBC).
1
Definir um projeto. Descrever as fases de um projeto. Definir gerenciamento de
projetos. Listar habilidades de gerenciamento de projetos. Discernir o que um
gerenciamento efetivo de projetos e reconhecer a sua necessidade.
conceitos
Projetos. Gerenciamento de Projetos. Gerenciamento Efetivo de Projetos. Sucesso ou

falha em Projetos
11 Muitas empresas tm investido em mltiplos projetos de Tecnologia da Informao (TI).
11 Gerentes de projeto possuem a responsabilidade de gerenciar e trabalhar pelo

sucesso de seus projetos.
11 Identificar os aspectos bsicos de um projeto tpico de TI em comparao com projetos de outras reas.
22 Identificar as diferentes fases de um projeto de TI.
22 Identificar os diferentes stakeholders de um projeto de TI.
22 Identificar requisitos de negcios para realizao de uma anlise de sistemas.
22 Criar um documento de escopo e obter aprovao dos stakeholders.
22 Criar uma WBS.
22 Realizar uma anlise de riscos.
22 Desenvolver estimativas de esforo, tempo e custo.
22 Criar planos de gerenciamento de projetos das diversas subreas de conhecimento: fornecedores, recursos, comunicao e qualidade.
22 Acompanhar o projeto e resolver problemas.
22 Gerenciar recursos, qualidade, o time de projeto e mudanas.
22 Reconhecer a importncia do encerramento de um projeto.
22 Identificar lies aprendidas e preparar um relatrio de projeto.
Nos dias de hoje, quando se observa uma expanso constante no campo da informao e da
tecnologia de internet, muitas empresas tm investido em mltiplos projetos de Tecnologia da
Informao (TI), com o objetivo de obter uma margem competitiva na nova economia. Gerentes
de projeto possuem a responsabilidade de gerenciar e conferir sucesso aos seus projetos.
Captulo 1 - Motivao
objetivos
Motivao
Este curso cobre aspectos bsicos na gesto de um projeto de TI, atravs do uso de uma
abordagem estruturada a guiar o estudante nas principais fases de um projeto de TI,
incluindo a definio de escopo, planejamento, execuo e encerramento. Ou seja, durante
este curso, o estudante receber informaes suficientes para:
11 Identificar os aspectos bsicos de um projeto tpico de TI em comparao com projetos
de outras reas;
11 Identificar as diferentes fases de um projeto de TI;
11 Identificar os diferentes stakeholders de um projeto de TI;
11 Identificar requisitos de negcios para a realizao de uma anlise de sistemas;
11 Criar um documento de escopo e obter a aprovao dos stakeholders;
11 Criar uma WBS;
11 Realizar uma anlise de riscos;
11 Desenvolver estimativas de esforo, tempo e custo;
11 Criar planos de gerenciamento de projetos das diversas subreas de conhecimento: fornecedores, recursos, comunicao e qualidade;
11 Acompanhar o projeto e resolver problemas;
11 Gerenciar recursos, qualidade, o time de projeto e mudanas;
11 Reconhecer a importncia do encerramento de um projeto;
11 Identificar lies aprendidas e preparar um relatrio de projeto.
Foco do curso
11 Realizar de maneira bem feita o trabalho correto.
11 Em projetos de TI, ou o projeto no foi entregue dentro do prazo ou no tinha a funcionalidade inicialmente requerida.
22 Organizao.
22 Ferramentas.
22 Recursos.
22 Abordagem.
Este curso foi criado para enderear um dos desafios mais significativos em TI realizar
de maneira bem feita o trabalho correto. Em projetos de TI, provavelmente uma das duas
situaes acontecem: ou o projeto no foi entregue dentro do prazo ou no tinha a funcionalidade inicialmente requerida. O desenvolvimento deste curso se iniciou com um estudo
profundo e uma anlise das tendncias atuais de TI na indstria e nos vrios fatores de
Gerenciamento de Projetos de TI
sucesso ou falha com papel crtico em um projeto.
O contedo deste curso foi elaborado atravs da coleta das perspectivas de vrios especialistas nesse campo, com conhecimento extenso de TI e de gesto de projetos, que forneceram as suas vises sobre o que realmente preciso saber para gerenciar de maneira
efetiva um projeto nessa indstria.
Diferentemente de outros cursos da rea de gerenciamento de projetos, este curso
baseado nos aspectos crticos de gerenciamento de projetos que precisam ser endereados,
de maneira que profissionais de TI e gerentes de projeto possam buscar excelncia em um
ambiente de TI.
Para tanto, de maneira geral, os tpicos a seguir sero discutidos:

11 Organizao;
11 Ferramentas;
11 Recursos;
11 Abordagem.
Organizao
11 Fases de um processo de gerenciamento de projetos, refletindo a forma como
gerentes de projeto de TI usam diferentes tcnicas de gesto.

11 Utilizar experincias do mundo real no campo de gerenciamento de projetos de TI.
11 As atividades de um projeto de TI no so equivalentes s de outros tipos de projeto.
11 No ambiente de TI, mais difcil especificar o trabalho.
11 Os recursos que planejam a soluo so aqueles que executam o trabalho.
11 A maioria das empresas de TI possui mltiplos projetos que acontecem simultaneamente, mas que esto estruturalmente relacionados.
11 muito comum que a iniciao e o sucesso de um projeto dependam do resultado de
outro projeto.
11 H o acompanhamento tanto de atividades de desenvolvimento quanto de atividades
no funcionais.
11 O gerenciamento de projetos de TI envolve a necessidade de suporte repetitivo e
projetos de manuteno.
11 Projetos de TI podem possuir oramentos anuais.
11 A grande maioria de projetos de TI no finalizada.
Este curso organizado de acordo com as fases de um processo de gerenciamento de projetos,
refletindo a forma como gerentes de projeto de TI usam diferentes tcnicas de gesto. A ideia
utilizar experincias baseadas em situaes do mundo real no campo de gerenciamento de
projetos de TI. A experincia prtica nessa rea mostra que todas as atividades nas diferentes
fases de um projeto de TI no so equivalentes s atividades de outros tipos de projeto.
No ambiente de TI, normalmente mais difcil especificar o trabalho, e os recursos que
planejam a soluo so aqueles que executam o trabalho. Se compararmos com a rea da
construo civil de onde a teoria de gerenciamento de projetos primariamente derivada
, observaremos que o trabalho mais serial e as responsabilidades de um arquiteto so
totalmente distintas das de um carpinteiro, por exemplo.
Alguns aspectos de diferenciao entre o gerenciamento de projetos de TI e um gerenciamento de projetos tradicional:
11 A maioria das empresas de TI possui mltiplos projetos que acontecem simultaneamente,

mas que esto estruturalmente relacionados. Muito comumente, a iniciao e o sucesso
de um projeto podem depender do resultado de outro projeto;
11 H o acompanhamento tanto de atividades de desenvolvimento quanto de atividades
no funcionais;
Captulo 1 - Motivao
11 Como foi dito, os recursos que planejam a soluo so aqueles que executam o trabalho;
11 Gerenciamento de projetos de TI envolve a necessidade de suporte repetitivo e projetos

de manuteno;
11 Projetos de TI podem possuir oramentos anuais;
11 A grande maioria de projetos de TI no finalizada.
Empresas sem um desempenho aceitvel
50%
45%
Empresas com um desempenho aceitvel

50%
45%
46.9%
40%
40%
35%
35%
30%
25%
18.8%
20%
15%
10%
38.8%
30%
25.0%
25%
46.3%
20%
15%
9.4%
13.4%
10%
5%
0.0%
0%
Projeto est
Projeto
fracassando
no nem
ou quase
bem-sucedido
fracassando
nem fracassado
5%
0%
0.0%
1.5%
Projeto est
Projeto
fracassando
no nem
ou quase
bem-sucedido
fracassando
nem fracassado
absoluto
Projetos com baixa qualidade nestas trs reas
profundidade necessria para melhorar as chances de sucesso do projeto. Dentro dessa

abordagem, o foco do curso so as principais aes requeridas para um gerenciamento de
projetos de sucesso e as formas como essas aes podem ser aplicadas para diferentes
tipos de projetos.
11 A funo do gerente de projetos alcanar o objetivo final do projeto.
11 H muitos caminhos para atingir o objetivo final.

11 Uma empresa pode obter os componentes de um projeto de diferentes formas,
dependendo de seus processos, procedimentos e cultura organizacional.
11 O gerenciamento de projetos:
22 Preocupa-se com a realizao do trabalho, certificando que feito corretamente.
22 No depende de uma metodologia de desenvolvimento particular.
22 Muitas empresas possuem uma metodologia de projetos padro.
A funo do gerente de projetos alcanar o objetivo final do projeto. H muitos caminhos
para o alcance do objetivo final, e uma empresa pode obter os componentes de um projeto de
um sucesso
absoluto
Quando as empresas eliminam a baixa

qualidade nestas trs reas
A ideia deste curso refletir esses aspectos de maneira que cada fase seja coberta na
Projeto
Projeto
um sucesso
diferentes formas, dependendo de seus processos, procedimentos e cultura organizacional.

Ao levar isso em considerao, este curso no vai apresentar uma metodologia simples de
gerenciamento de projetos. Em outras palavras, no vai prescrever como realizar as atividades de gerenciamento de projetos. Note que o gerenciamento de projetos e as metodologias de desenvolvimento de produtos algumas vezes so confundidos.
As metodologias de desenvolvimento de produto disponibilizam detalhes de como o
trabalho ser realizado. Por exemplo, a ISO 9001 requer que um processo de design inclua
atividades como definio de requisitos, planejamento, verificao e validao. O gerenciamento de projetos tambm inclui a definio de requisitos e planejamento, mas os requi-
Figura 1.1
Anlise de negcio
sobre finalizao de
projetos.
sitos de projeto e os planos tendem a ser mais abrangentes do que aqueles necessrios para
o desenvolvimento de produtos.
Em resumo, gerenciamento de projetos se preocupa com a realizao do trabalho e certifica
que o trabalho realizado de maneira adequada. Gerenciamento de projetos no depende
de uma metodologia de desenvolvimento particular.
Muitas empresas possuem uma metodologia de projetos padro para a sua organizao.
11 Ferramentas permitem planejar e acompanhar o progresso do projeto:
22 Microsoft Project.
22 Artermis Views 4.
22 Enterprise Project.
22 Project Workbench.
11 preciso entender os procedimentos e processos de gerenciamento de projetos para
que o uso de tais ferramentas seja efetivo.
11 A escolha da ferramenta apropriada depende:
22 Da complexidade do projeto.
22 Do nvel da experincia do time com aquele software em particular.
22 Dos padres da organizao executora.
O artigo Project Management: Software Comparison Columns (Daniel Stang, 2009)
compara diversos softwares de gerenciamento de projetos nessa rea. Existem ainda
vrias ferramentas de gerenciamento de projetos baseadas na web, que possibilitam
o gerenciamento de projetos de qualquer parte do mundo, atravs da internet. Os mais
proeminentes so: WebProject (www.wproj.com), da Novient; Mesa/Vista Project
Manager (www.mesasys.com), da Mesa Systems Guild, Inc.; Project Management SW
(www.project.net) e Vertabase (www.vertabase.com).
Ferramentas
Este curso no vai estender-se no uso de ferramentas de gerenciamento de projetos, mas
vai mencionar ferramentas que podem ser utilizadas durante o gerenciamento de projetos.
Ferramentas como o Microsoft Project, Artermis Views 4, Enterprise Project, ou Project
Workbench fornecem ao gerente de projetos a habilidade de planejar e acompanhar o progresso do projeto. Entretanto, necessrio um entendimento consoante de procedimentos
e processos de gerenciamento de projetos para que seja efetivo o uso de tais ferramentas.
A escolha da ferramenta apropriada depende da complexidade do projeto, do nvel da experincia do time com aquele software em particular e dos padres da organizao executora.
recente em termos de softwares para gerenciamento de projetos, dentro de google.com:
11 Business > Management > Project and Program Management:
http://directory.google.com/Top/Computers/Software/Project_Management/
11 Computers > Software > Project Management:
http://directory.google.com/Top/Computers/Software/Project_Management/
Captulo 1 - Motivao
A seguir, esto pginas da web que podem ser utilizadas para a obteno do que h de mais
Recursos
Existem diversos recursos de gerenciamento de projetos de TI e gerenciamento de
projetos em geral:
11 The International Journal of Project Management.
11 Project Management Journal (PMJ).
11 InfoSystems Executive.
11 PM Network.
11 Breakthrough Technology Project Management:
22 Kathryn P. Rea, Bennet P. Lientz (1998); Academic Pr.
11 Project Management: Best Practices for IT Professionals:
22 Richard Murch; Hardcover (2000); Prentice Hall.
11 IT Managers Handbook: Getting Your New Job Done:
22 Bill Holtsnider, Brian D. Jaffe (2000); Morgan Kaufmann Publishers
11 IT Professionals Guide to Managing Systems, Vendors and End Users:
22 Neil Plotnick; Paperback (1999); Osborne Pub.
11 Course ILT: IT Project Management:
22 Course Technology (Editor), Course Technology; Paperback (2000); Course Technology.
H diversos recursos disponveis para se lidar com gerenciamento de projetos em geral e
gerenciamento de projetos de TI em particular, entre os quais podemos citar:
The International Journal of Project Management

Publicao oficial da International Project Management Association (IPMA), esse jornal bimestral oferece cobertura compreensiva de basicamente todas as faces do gerenciamento de
projetos. focalizado na experincia internacional em tcnicas, prticas e reas de pesquisa, e
apresenta um frum para seus leitores compartilharem experincias nas diferentes indstrias
e tecnologias de gerenciamento de projetos. Cobre todos os aspectos do gerenciamento de
projetos, de sistemas a aspectos humanos, relacionando teoria com prtica atravs da publicao de estudos de caso retirados de importantes publicaes sobre o tema.
Project Management Journal (PMJ)

O PMJ publicado pelo Project Management Institute (PMI), com o objetivo de ser uma voz
para o gerenciamento de projetos. Procura publicar artigos teis e significativos que se relacionam com as diversas reas no campo de gerenciamento de projetos, de maneira a obter
um balano editorial de filosofia, tcnica, teoria, prtica e comentrios, para ser um frum
de livre discusso de problemas relacionados ao gerenciamento de projetos, solues, apli-
caes e opinies. O PMJ publicado em maro, junho, setembro e dezembro.
InfoSystems Executive
Essa revista apoia executivos em corporaes e em sistemas de informao no gerenciamento de informaes na nova economia. A cada publicao so disponibilizados estudos
de caso de gerenciamento de projetos de TI.
PM Network
A revista mensal do PMI contm artigos que consolidam o estado da arte da prtica do
gerenciamento de projetos e disponibiliza os captulos e membros do PMI, alm de novidades sobre o instituto. recomendvel ainda a pesquisa a sites e recursos relacionados ao
gerenciamento de projetos.
Abordagem
A abordagem para o aprendizado prtica, com discusso dos participantes, exerccios e
estudos de caso servindo como componentes primrios. Muitas sesses se iniciam com
perguntas para conhecer o grau de conhecimento atual dos participantes, sendo essas
questes o guia para orientar o processo de ensino-aprendizado.
Introduo ao Gerenciamento de Projetos de TI

11 Objetivos.
11 Exerccios de nivelamento.
11 Introduo.
11 O que um projeto?
11 O que gerenciamento de projetos?
11 Qualificaes em gerenciamento de projetos.
11 Por que gerenciamento de projetos necessrio?
11 Checklist de um projeto arruinado.
11 Principais fatores para o sucesso de um projeto.
11 O custo da falha: exemplo.
11 Concluses.
11 Exerccios de fixao.
Objetivos
Ao completar essa sesso, o aluno ser capaz de:
11 Definir um projeto;
11 Descrever as fases de um projeto;
11 Definir gerenciamento de projetos;
11 Listar habilidades de gerenciamento de projetos;
11 Discernir o que um gerenciamento efetivo de projetos e reconhecer a sua necessidade;
11 Identificar razes para o sucesso ou falha de um projeto.
Exerccios de nivelamento e
1. O que constitui um projeto?
Captulo 1 - Motivao
Estado da arte
o nvel mais alto de
desenvolvimento de um
equipamento, de uma
tcnica ou de uma rea
cientfica, alcanado
em um tempo definido.
Quando a tcnica ou
objeto se torna uma
espcie de obra-prima.
2. Quem o gerente de projeto?
3. Cite um software conhecido para gerenciamento de projetos.
4. Qual a diferena entre gerenciamento de projetos de TI e de outros tipos de projeto?
5. Cite dois fatores que podem tornar um projeto bem-sucedido.
Introduo
Esta sesso introduz e define um projeto e gerenciamento de projetos. As diferenas entre um
projeto de TI e outros tipos de projeto sero discutidas, assim como os fatores que acarretam
em sucesso ou falha de um projeto. Veremos as quatro fases principais do gerenciamento de
projetos de TI e as habilidades de um bom gerente de projetos sero descritas em detalhes.
O que um projeto?
Podemos definir um projeto como qualquer srie de atividades e tarefas que contm
o seguinte:
11 Um objetivo especfico para ser completado dentro de especificaes.
11 Datas de incio e fim definidas.
11 Limites de custos.
11 Recursos utilizveis.
Um projeto acontece apenas uma vez e, ento, finalizado.
De acordo com o PMBoK, um projeto um esforo temporrio empreendido para criar um
produto, servio ou resultado exclusivo. A sua natureza temporria indica um incio e trmino
definidos. O trmino alcanado quando os objetivos tiverem sido atingidos, quando se concluir que esses objetivos no podero ser atingidos ou quando este no for mais necessrio.
Podemos definir um projeto como qualquer srie de atividades e tarefas que contm
o seguinte:
11 Um objetivo especfico para ser completado dentro de especificaes;
11 Datas de incio e fim definidas (por exemplo, um cronograma);
11 Limites de custos (por exemplo, um oramento);

11 Recursos utilizveis (dinheiro, pessoas, equipamento e suprimentos);
11 Um projeto acontece apenas uma vez e, ento, finalizado.
Particularidades de projetos de TI
11 Alm das caractersticas comuns a todos os projetos, projetos de TI possuem algumas
particularidades a mais, que demandam do gerente de projetos uma habilidade ainda

maior de liderana tcnica e interpessoal.
11 Entre elas, podemos citar:
22 Intangibilidade de boa parte dos entregveis (especialmente em projetos de software).
22 Dificuldade de identificar os requisitos e acompanhar o progresso.
22 Estimativas de tempo medidas em homens/hora.
11 Recomenda-se um nvel mnimo de conhecimento tcnico por parte do gerente de
projetos de TI.
11 Sem conhecimento tcnico, garantir o planejamento adequado e o progresso aceitvel
de cada uma das atividades do projeto torna-se uma atividade bem mais complexa.
Gerenciar projetos aplicar as habilidades, conhecimentos, ferramentas e tcnicas j consagradas com o objetivo de alcanar os requisitos do projeto.
Projetos de TI possuem particularidades distintas em relao a outros tipos de projetos. Entre
elas destaca-se a dificuldade em se identificar claramente os requisitos e de acompanhar o
progresso do projeto. Se um sistema intangvel, como controlamos o seu desenvolvimento?
Diferena entre projetos e processos

11 importante estabelecer uma diferena bsica entre um projeto e um processo.
11 Projetos se caracterizam por serem nicos e temporrios.

11 Processos so operaes de natureza contnua e repetitiva.
Exemplos de projeto:
11 Desenvolvimento de um software;
11 Lanamento de um novo produto;
11 Construo de uma fbrica;
11 Montagem de um datacenter.
No so exemplos de projetos:
11 Gerenciamento de uma rede de computadores;
11 Fabricao de um automvel;
11 Manuteno de equipamentos.
O que gerenciamento de projetos?

Gerenciamento de projetos um processo iterativo que envolve cinco fases principais
(MGP-SISP), como mostra a tabela 1.1.
Captulo 1 - Motivao
11 Compra de insumos e materiais;
Fase
Planejamento
Iniciao
Planejamento
Denio de
Execuo
Escopo
Monitoramento e Controle
Execuo
Tabela 1.1
Fases de
gerenciamento
de projetos.
Encerramento
Encerramento
1. Iniciao
2. Planejamento
3. Execuo
5. Enceramento
Figura 1.2
As fases do
gerenciamento.
4. Monitoramento e Controle
Fase
Descrio
Iniciao
Descreve o qu, quem, onde, quando, por que e como de um projeto; a iniciao de um
projeto tem foco nas motivaes do projeto e no que o projeto realizar.
So processos realizados para definir um novo projeto e obter autorizao formal para
inici-lo.
Planejamento
Descreve como o escopo ser alcanado, com atividades detalhadas e estimativas de tempo
(quando), custos e recursos alocados (quem). Planeja as aes do projeto a fim de alcanar
os objetivos para os quais ele foi criado.
Execuo
Distingue entre atividades de projeto (desenvolvimento, testes) e o gerenciamento de projetos. Enfatiza o gerenciamento de times e o acompanhamento e reporte de atividades.
Monitoramento
e Controle
Observa a execuo do projeto para identificar possveis problemas e habilita a tomada de

aes preventivas e corretivas quando necessrio. O principal objetivo observar o desempenho do projeto regularmente para identificar variaes em relao ao plano.
Encerramento
Inquirir, revisar tempo e performance de custos, comemorar, compilar lies aprendidas e

planejar atividades futuras.
Estgios do ciclo de gerenciamento de projetos

11 Estgio de planejamento e escopo.
11 Observar o problema com clareza.
10
11 Restringir o escopo do projeto.

22 Delimitar expectativas na realidade.
22 Negociao (por exemplo, disponibilidade de recursos e fundos).
11 Traduzir requisitos de negcio em especificaes de projeto.
11 Elencar e gerenciar riscos.
11 Estimar custos.
Tabela 1.2
Descrio de cada
uma das fases.
11 Associar atividades a marcos de performance, e marcos de performance a
entregveis de projeto.
11 Estabelecer prioridades.
11 Estimar cronograma (alinhando conhecimento e tempo).
11 Execuo.
11 Construir times de projeto.
11 Facilitar comunicao, cooperao e colaborao:
22 Manter gerentes de negcio informados.
22 Negociar e gerenciar mudanas.
22 Garantir suporte da alta-gerncia.
11 Identificar mtricas e marcos crticos.
11 Gerenciar hand-offs (transio) entre grupos.
11 Documentar pontos positivos e negativos durante o projeto.
11 Garantir a relevncia permanente do projeto.
Para garantir a eficincia do gerenciamento de projetos, necessrio que os seguintes
estgios do ciclo de gerenciamento sejam observados.
Estgio de planejamento e escopo

11 Observar o problema claramente.
11 Restringir o escopo do projeto.
22 Delimitar expectativas na realidade.
22 Negociao (por exemplo, disponibilidade de recursos e fundos).
11 Traduzir requisitos de negcio em especificaes de projeto.
11 Elencar e gerenciar riscos.
11 Estimar custos.
11 Associar atividades a marcos de performance, e marcos de performance a entregveis de
projeto.
11 Estabelecer prioridades.
11 Estimar cronograma (alinhando conhecimento e tempo).
Execuo
11 Construir times de projeto.
11 Facilitar comunicao, cooperao e colaborao.
22 Manter gerentes de negcio informados.
22 Garantir suporte da alta-gerncia.

11 Identificar mtricas e marcos crticos.
11 Gerenciar hand-offs (transio) entre grupos.
11 Documentar pontos positivos e negativos durante o projeto.
11 Garantir a relevncia permanente do projeto.
Captulo 1 - Motivao
22 Negociar e gerenciar mudanas.
11
Por que o gerenciamento de projetos necessrio?

11 Muitos projetos de TI falham porque no foram gerenciados adequadamente.
11 Dois fatores tm influenciado essa performance to fraca:

22 Falta de disciplina em gerenciamento de projetos.
22 Falta de comunicao entre a organizao de TI e os diretores de unidade de negcio.
Muitos projetos de TI falham porque no foram gerenciados adequadamente. Projetos de TI
tm custado s empresas milhes de dlares, dependendo do tipo do projeto. Com o objetivo
de reduzir o risco de tais perdas, aumentar a competitividade e implementar projetos de TI
com sucesso, as empresas tm dedicado mais ateno a uma abordagem disciplinada para o
gerenciamento de projetos de TI. O tamanho dos projetos ser estudado nesta sesso.
Pesquisa do Standish Group, cujos resultados esto disponveis em: http://spinroot.com/
spin/Doc/course/Standish_Survey.htm, mostrou que 31,1% dos projetos de TI, depois de
iniciados, sero cancelados antes que sejam aproveitados para algo, representando perda
de US$ 75 bilhes por ano. Em mdia, 52,7% dos projetos de TI excedem o oramento em
at 189%, enquanto apenas 74,2% das funcionalidades inicialmente acordadas so, de fato,
entregues. Dois fatores tm influenciado essa performance to fraca:
11 Falta de disciplina em gerenciamento de projetos;
11 Falta de comunicao entre a organizao de TI e os diretores de unidade de negcio.
Tamanho de projetos
O mesmo estudo mostrou que h uma taxa de 90% em falhas de projetos com oramentos
superiores a US$ 6 milhes. Em termos de mtricas como custo e cronograma, essas falhas
podem ser consideradas crticas o suficiente para o cancelamento do projeto. Estudos
atuais na indstria tambm mostram uma correlao positiva entre o tamanho dos projetos
e falhas de maneira que mesmo projetos pequenos de internet podem demandar um
gerente de projetos altamente capacitado.
Checklist de um projeto arruinado

Os seguintes itens podem ser listados como os maiores responsveis pelo insucesso em
projetos de TI:
11 Um patrocinador sem envolvimento ativo na estratgia e direo do projeto.
11 Plano de projetos ausente, desatualizado, incompleto ou mal feito, exigindo quando
possvel o uso de metodologias geis de gerenciamento.
11 Mudanas frequentes na gerncia do projeto.
11 Times constitudos por provedores externos de servio, e equipe interna sem definio clara e formal de responsabilidades e relacionamentos.
11 Ausncia da definio dos benefcios que sero produzidos pelo projeto e falta de
entendimento da relao destes com os entregveis do projeto que produziro esses
benefcios.
11 Controle de mudanas insuficiente ou inexistente.
11 Mudanas de tecnologia durante o projeto.
11 Ausncia de qualificaes suficiente na equipe.
11 Expanso incremental do escopo do projeto, resultando em um escopo genrico, sem
foco e no gerencivel (scope creep).
12
Principais fatores para o sucesso de um projeto

Os seguintes itens podem ser listados como os maiores responsveis pelo sucesso de
um projeto de TI:
11 Governana formal e processos bem definidos para aprovao de mudanas.
11 Patrocinadores responsveis pelos resultados do projeto.
11 Treinamento em gerenciamento de projetos.
11 Sistemas de feedback.
11 Definio formal de prioridades para requisies e mudanas.
11 Comunicao regular com usurios finais.
11 Acompanhamento claro de pessoas, qualificaes e tempo.
11 Existncia de um banco de dados das competncias tcnicas resilientes no projeto,
baseadas em qualificao.
11 Estimativas do projeto baseadas em contribuies de diferentes reas.
11 Ferramentas automatizadas de gerenciamento de projetos.
Exerccio de fixao 1 e
Falhas de gerenciamento de projeto
O gerente do projeto responsvel pela implementao de uma aplicao de preos (que seria
adotada por toda a empresa) precisou se ausentar durante seis meses por razes mdicas,
e o seu gerente de programas designou voc para substitu-lo, devido sua experincia com
aplicaes de preos.
A aplicao projetada vai considerar diversos fatores de preo nos seus clculos e permitir
que os vendedores disponibilizem para seus clientes preos em tempo aproximadamente
75% menor do que o processo manual atualmente utilizado.
Como a empresa primariamente com foco em vendas, e as projees de lucro para o
prximo ano so dependentes de cinco produtos que foram includos na primeira verso da
aplicao, esse projeto de altssima prioridade. Um dos cinco produtos novo, e os fatores
de preo ainda no foram claramente definidos para ele. Entretanto, o CEO direcionou que
esse produto fosse includo na aplicao. A bolsa de valores local j est especulando a
entrada desse produto nesse mercado to competitivo.
Seu gerente de programas lhe enviou uma cpia do plano de projetos e deseja marcar uma
reunio assim que voc tiver entendido a informao e se reunido com o time de projetos.
Durante a reunio com o time de projetos, voc descobre que:
11 O lder do time de banco de dados est se desligando da empresa. Ele projetou as tabelas
individualmente, sem compartilhar as informaes com outros membros;
para esse projeto acaba de ser realocado para um projeto de prioridade ainda maior.
Esse novo servidor no era parte do oramento inicial;
11 Existem dois novos membros do time de projeto: um gerente de produto para um dos cinco
produtos e um novo programador, que est trabalhando nas tabelas do banco de dados;
11 O time de desenvolvimento comunica que acabou incorporando mudanas na implementao sem nenhuma formalizao ou documentao.
Captulo 1 - Motivao
11 Um novo servidor deve ser adquirido, j que o servidor que fora inicialmente alocado
13
A notcia boa que o time bom, est motivado e disponvel para realizar mudanas
necessrias para garantir o sucesso do projeto. Solues sugeridas para esse cenrio esto
disponveis no Apndice B.
1. Liste as principais razes para uma possvel falha desse projeto, nesse cenrio.
Exemplo de custo da falha

Uma organizao de tamanho mdio de sistemas de informao passou dois anos desenvolvendo uma aplicao de negcios cuja instalao acabou sendo recusada pelos diretores de
negcio. O gerenciamento de projetos ineficiente foi definitivamente uma das falhas:
11 Nenhum gerente de projetos qualificado negociou recursos, tempo e qualificaes
para a equipe;
11 Similarmente, nenhum diretor de negcios documentou ou negociou requisies das
diferentes divises de negcio;
11 Para finalizar, a organizao executora e a direo de negcios no foram envolvidas na
elaborao e na reviso do escopo do projeto e dos requisitos.
No fim, a aplicao estava desatualizada seis meses antes da data estimada para o release.
Gerenciamento bem-sucedido de projetos
Descreva e analise as qualificaes necessrias para ser um gerente de projetos de sucesso.
Durao aproximada: 20 minutos.
1. Baseado na sesso Checklist para um projeto arruinado e Principais fatores para o
sucesso de um projeto, o que um gerente de projetos precisa fazer para ter sucesso?
14
2
Identificar os stakeholders, requisitos e consideraes. Definir a necessidade de
negcio formal e razes informais para um projeto de TI. Definir o escopo preliminar
de um projeto de TI. Mapear os requisitos de negcio em requisitos tcnicos e funcionais.
Identificar os papis e responsabilidades do gerente de projetos, do patrocinador e
do time de projetos. Identificar os componentes de um documento de escopo
conceitos
Stakeholders. Justificativa de Projeto. Escopo e Requisitos. Papis e responsabilidades
Exerccios de nivelamento e
1. O que iniciao?
2. Quem um stakeholder?
2.1.Quem cria um termo de abertura de projeto?
3. O mapeamento de riscos no faz parte de um documento de escopo:

[a]Verdadeiro
[b] Falso
4. A aprovao e o consenso dos stakeholders so necessrios antes da fase de planejamento de um projeto:
[a] Verdadeiro
[b] Falso
Captulo 2 - Iniciao
objetivos
Iniciao
15
Introduo
Definio do escopo,
a primeira fase do ciclo de vida de um projeto de TI.
Planejamento
Nesta sesso, estudaremos a iniciao, que a primeira fase do ciclo de vida de um projeto
de TI, com a sua aprovao formal. O gerente de projetos, os patrocinadores do projeto e o
Denio
deprojeto sero introduzidos, e seus papis e responsabilidades, detalhados.
time de
Execuo
Escopo
O termo de abertura do projeto e seus componentes tambm sero discutidos em detalhe.
A importncia de um documento de escopo enfatizada como um documento padro que
ser usado durante o resto do projeto. A figura 2.1 ilustra a definio do escopo e como ela
Encerramento
se encaixa no processo de gerenciamento do projeto.
1. Iniciao
2. Planejamento
3. Execuo
5. Enceramento
Figura 2.1
Definio do
escopo e o
gerenciamento
do projeto.
Definio do escopo
11 A definio do escopo a base de qualquer projeto de TI.
11 Definir e documentar o escopo o primeiro passo do gerenciamento de projetos.

11 Definir o escopo de um projeto significa:
22 Identificar o problema ou oportunidade que ser endereada pelo projeto.
22 Os objetivos e metas do projeto.
22 Como o sucesso ser medido.
22 Os riscos, obstculos e consideraes que podem afetar o resultado.
11 A primeira atividade da identificao do escopo de um projeto inclui avaliar a necessidade
de negcios expressa e definir os esforos necessrios para atender a tal necessidade.
11 O prximo conjunto de atividades refinar o conceito do projeto.
11 fase de escopo frequentemente dada menos ateno do que a outras fases de projeto.
11 importante lembrar que a qualidade no planejamento delimitada pela definio
do escopo do projeto.
11 Sem um escopo preciso e bem definido, um projeto est fadado ao fracasso.
11 Definir o escopo significa identificar claramente um problema, os objetivos e metas

do projeto, e como sero alcanados.
A definio do escopo a base de qualquer projeto de TI. Definir e documentar o escopo
so os primeiros passos do processo do gerenciamento de projetos. Definir o escopo de um
projeto significa:
11 Identificar claramente o problema ou oportunidade que ser endereado pelo projeto;
11 Estabelecer os objetivos e metas do projeto;
11 Definir como o sucesso ser medido, seus riscos e obstculos, e ainda consideraes que
podem afetar o resultado;
16
11 Anlise de custo e benefcio;

11 Anlise de retorno de investimento (ROI): estimativa da taxa interna de retorno e os delimitadores do projeto (tempo, custo e recursos).
A primeira atividade da identificao do escopo de um projeto inclui avaliar a necessidade de
negcios expressa e definir os esforos necessrios para o atendimento de tal necessidade.
O prximo conjunto de atividades estabelece o refinamento do conceito do projeto. Componentes como a identificao dos stakeholders, a anlise de requisitos de sistema e o
mapeamento de riscos adicionam informaes detalhadas definio do projeto, auxiliando
a organizar a definio de delimitadores do projeto.
fase de escopo frequentemente dada menos ateno do que a outras fases de projeto.
importante lembrar que a qualidade no planejamento de um projeto delimitada pela
definio do seu escopo, j que sem um escopo preciso e bem definido o projeto estar
fadado a falhar. Todas as fases subsequentes do projeto so baseadas nas informaes
obtidas e documentadas na fase de delimitao do escopo.
Determinar o escopo identificar com clareza os objetivos e metas do projeto, e o

modo como sero alcanados.
Identificando expectativas e necessidades dos stakeholders

11 A identificao das pessoas e organizaes que podem ajudar ou atrapalhar o resul-
tado de um projeto fundamental para o seu sucesso.

11 papel do gerente do projeto realizar duas atividades para garantir que o projeto
ser realizado:
22 Identificar os stakeholders.
22 Definir os requisitos dos stakeholders.
Durante essa fase, so identificados os principais participantes e stakeholders, assim como
seus papis e responsabilidades. Os principais stakeholders incluem patrocinador, cliente,
usurios finais, time de projeto, gerentes de projeto, organizaes envolvidas e demais entidades ou indivduos envolvidos com o projeto.
Os requisitos e expectativas dos stakeholders devem ser identificados atravs de diferentes
mtodos de comunicao, que incluem entrevistas pessoais, questionrios, reunies de grupo
e grupos de foco. Durante a fase de identificao de requisitos dos stakeholders, todas as
consideraes so anotadas e esta lista mantida e utilizada durante o ciclo do projeto.
Os seguintes assuntos devem ser discutidos:
11 Identificao dos stakeholders;
Identificando os stakeholders
Os stakeholders so indivduos e organizaes cujos interesses podem ser afetados
pelo projeto. Os stakeholders podem ser:
11 Proprietrios do investimento do projeto.
11 Fonte de recursos financeiros.
Captulo 2 - Iniciao
11 Definio dos requisitos dos stakeholders.
11 Cliente.
17
11 Patrocinador do projeto.
11 Diretor do projeto.
11 Gerente de programa, lder ou coordenador.
11 Time de projeto, grupo ou fora de trabalho.
11 Usurios.
11 Grupos de negcio.
11 Pblico em geral.
11 Mdia.
Os stakeholders so indivduos e organizaes cujos interesses podem ser afetados pelo projeto.
Podem ser de diversas naturezas e influenciar o projeto em diferentes reas e momentos.
Existem stakeholders que esto presentes em todos os projetos de TI, tais como:
11 O proprietrio do investimento do projeto;
11 A fonte de recursos financeiros;

11 O cliente;
11 O gerente do projeto;
11 O time do projeto.
H tambm stakeholders que se aplicam em apenas alguns projetos, com sua existncia
atrelada disposio organizacional da empresa executora e natureza do projeto.
Podemos citar os seguintes stakeholders como pertencentes a esta categoria:
11 Patrocinador do projeto, presente na maioria dos projetos de TI;
11 Diretor do projeto;
11 Gerente de programa (papel cada vez mais comum), lder ou coordenador;
11 Usurios;
11 Grupos de negcio;
11 Pblico em geral;
11 Mdia.
importante identificar os papis que se aplicam ao projeto e at mesmo propor a ocupao
de determinadas funes para garantir a execuo aceitvel do projeto.
Para identificar os stakeholders, normalmente necessria a anlise do ambiente do
projeto e a coleta de dados da organizao:

11 Anlise do ambiente do projeto.
11 Determinao do tipo de influncia.
18
11 Categorizar o nvel de influncia.

11 Coletar informaes.
Para identificar os stakeholders, normalmente necessria a anlise do ambiente do projeto
e a coleta de dados da organizao:
Anlise do ambiente do projeto
Identificao dos grupos que podero ser afetados pelo projeto ou que podero influenci-lo.
Determinao do tipo de influncia

Organizao dos indivduos e grupos de acordo com o tipo de influncia que eles podem
ter. Por exemplo, os stakeholders podem ter contato direto com o resultado ou produto
do projeto. Outro exemplo seria o stakeholder que tenha uma relao hierrquica com o
projeto, como controle financeiro ou influncia sobre as condies fsicas, tecnolgicas,
comerciais, polticas ou legais do projeto.
Categorizar o nvel de influncia
Categorizar o nvel da influncia de cada stakeholder sobre o projeto. Grupos de stakeholders podem compartilhar o mesmo tipo de influncia.
Coletar informaes
O que necessrio saber sobre cada stakeholder? Onde e como se pode obter a informao? Quem ser responsvel pela coleta, anlise e interpretao dos dados que sero
coletados sobre cada stakeholder?
Tabela 2.1
Stakeholders
e seus papis.
Papis comuns de stakeholders

Os seguintes stakeholders e seus papis so comuns em projetos de TI:
Stakeholder
Papel
Patrocinador
(sponsor)
11O indivduo ou organizao que inicia o trabalho e prov recursos.

11Um membro da alta gerncia um exemplo de patrocinador.
11Um cliente que encomendou o projeto pode ser considerado um patrocinador externo.
Cliente
O indivduo ou organizao que ir receber o servio ou hardware gerado pelo projeto.

O cliente pode ser o patrocinador.
Usurios finais
Em um projeto de TI, as pessoas que sero afetadas pelas novas tecnologias.
Organizao
executora
Os indivduos que formam o time organizacional de projeto.
Outros indivduos/
organizaes
Aqueles influenciados e afetados pelo projeto (como funcionrios, consultorias

e subcontratados).
Time de projeto
Profissionais tcnicos e outros especialistas que servem e esto alocados ao projeto.
Gerente do projeto
O indivduo responsvel por gerenciar o projeto.
Definindo os requisitos dos stakeholders

11 necessrio identificar as necessidades, expectativas e requisitos dos stakeholders
para garantir a gesto de fatores crticos para o sucesso de um projeto.

11 Para cada stakeholder, o significado de sucesso pode variar.
22 Podem se relacionar com fatores clssicos do gerenciamento de projetos, como

tempo, custo e qualidade.
22 Podem se relacionar com particularidades organizacionais, como mudanas na
organizao e autoridade para tomada de deciso.
11 Tambm importante determinar at que ponto o tempo, o custo e a qualidade do
projeto so importantes para os diversos stakeholders.
Captulo 2 - Iniciao
11 Os requisitos podem ser de diversas naturezas:
19
necessrio identificar as necessidades, expectativas e requisitos dos stakeholders para

garantir a gesto de fatores crticos para o sucesso de um projeto. Os fatores crticos para
o sucesso de um projeto so os principais indicadores do fracasso ou do sucesso de um
projeto. Esses indicadores mensuram a forma como as pessoas pensam os resultados do
projeto. Entretanto, para cada stakeholder, o significado de sucesso pode variar.
Os requisitos podem ter diversas naturezas, podendo tanto se relacionar com fatores
clssicos do gerenciamento de projetos (como tempo, custo e qualidade), quanto com particularidades organizacionais, como mudanas na organizao, autoridade para tomada de
deciso e participao em grupos de trabalho.
Tambm importante determinar at que ponto o tempo, custo e qualidade do projeto so
importantes para os stakeholders.
Mtodos para identificar requisitos

Diversos mtodos podem ser utilizados para determinar as necessidades dos
stakeholders, incluindo:
11 Reunies com grupos relacionados ao projeto.
11 Pesquisas de opinio.
11 Entrevistas.
Cada mtodo necessita empregar:
11 Questes subjetivas para conhecer todos os pontos de vista.
11 Questes objetivas especficas para dar foco em reas especficas.
Projetos que dedicam tempo para determinar as expectativas e necessidades daqueles que
podem afetar o seu resultado tm probabilidade bem maior de serem finalizados com o
feedback positivo de todos os envolvidos. Sugere-se a utilizao de mtodos como reunies
de grupos de foco, pesquisas de opinio e entrevistas para recolher requisitos embora,
na fase de planejamento do projeto, toda ideia seja bem-vinda. importante que o gerente
de projeto recolha o maior nmero de opinies e pontos de vista de todos os stakeholders
influentes em um ambiente de projeto. importante tambm garantir que reas especficas
sejam endereadas neste processo.
Os requisitos dos stakeholders vo variar, dependendo da perspectiva do indivduo.
importante frisar que a determinao das necessidades dos stakeholders deve ser um
processo diligente, mas que no pode atrasar a realizao do trabalho.
Razes para requisitos inadequados

Os requisitos podem estar inadequados por serem:

11 Incorretos.
11 Obscuros.
11 Inconsistentes.
11 Inexistentes.
A elaborao de requisitos tem sido historicamente um problema de gerenciamento de
projetos e do processo de licitao de requisitos de negcio. Requisitos incorretos, obscuros,

inconsistentes e inexistentes tm sido uma das causas das falhas nos projetos de TI. de
fundamental importncia que o gerente do projeto garanta que os requisitos foram listados,
acordados e formalmente aceitos por todos os stakeholders, antes do incio do projeto.
20
Sucesso uma
percepo subjetiva,
portanto, uma boa
ideia identificar as
pessoas que sero
afetadas pelo projeto e
seus respectivos
critrios de sucesso
ainda na fase de
planejamento do
escopo.
Cada uma dessas razes de falha normalmente tem uma causa diferente, sendo influenciada
por diferentes informaes e stakeholders.
Identificando consideraes
Para garantir o entendimento correto do escopo do projeto e do trabalho a ser realizado, o
gerente do projeto deve documentar consideraes que delimitem o entendimento com o

maior nvel de detalhe possvel. Essas especificidades podem ser de diversas naturezas:
11 Contingncia.
11 Risco.
11 Recursos de sistema.
11 Novas tecnologias.
11 Mudanas de design.
11 Funes de qualidade e de confiabilidade.
11 Consideraes de gerenciamento.
11 Audincia.
Enquanto o escopo revisado e desenvolvido, consideraes precisam ser documentadas
claramente, de maneira que o time de projetos e os stakeholders concordem com o direcionamento dos componentes bsicos do projeto. importante que uma lista cuidadosa de
consideraes seja elaborada e mantida durante e execuo do projeto.
Essas consideraes podem ser relativas a um nmero de influncias de projeto, tais como
aspectos relativos ao negcio (novas tecnologias, consideraes de gerenciamento), a restries do projeto (custos, contingncia, riscos, funes de qualidade), a caractersticas do
produto ou servio em desenvolvimento (recursos de sistema, mudanas de design) e aos
usurios para os quais o produto ou servio se destina (audincia do projeto).
Identificar e documentar consideraes ao longo da vida do projeto um fator crtico
para o seu sucesso.
Identificando requisitos de negcio

11 Toda necessidade por um projeto est associada a uma necessidade de negcio que
justifique um investimento.
11 A identificao de requisitos de negcio deve ser observada pelo gerente do projeto
como uma referncia para a realizao do trabalho.
11 Dessa forma, imprescindvel definir e, se for o caso, documentar:
22 A necessidade de negcio que o projeto atender.
22 As motivaes informais para um projeto.
A maioria dos projetos de TI motivada pelas necessidades de negcio que beneficiaro uma
organizao em longo prazo. Diferentes indivduos e stakeholders em um projeto possuem
opinies distintas sobre o projeto. Um balanced scorecard pode ser usado para diferenciar os
stakeholders e suas opinies, com mtricas para mensurao do sucesso. Um documento de
conceito de projeto tambm preparado nesse estgio, incluindo os entregveis finais e suas
funcionalidades associadas. Os seguintes tpicos sero discutidos:
Captulo 2 - Iniciao
22 O conceito preliminar do projeto.
21
11 Definio de necessidade de negcio.
11 Motivaes informais de projeto.

11 O conceito de projeto preliminar.
Definio de necessidade de negcio

11 A adequao dos projetos ao planejamento organizacional de uma empresa um
fator importantssimo para justificar a sua existncia.

11 Justificativas de negcio, como lucro e retorno de investimento, devem ser consideradas antes de se iniciar um investimento.
11 Os requisitos de negcio so identificados e definidos para responder a questes
como as seguintes:
22 Nossos projetos adicionam valor ao negcio?
22 Trazem benefcios realmente necessrios ao negcio?
22 Como est a performance do departamento de TI em completar seus projetos com
sucesso, e como melhorar seus ndices atuais?
22 Quo bem os projetos antecipam requisitos futuros?
Os projetos precisam estar aderentes aos objetivos de longo prazo de uma empresa. Todos
os projetos so investimentos e devem ter uma justificativa de negcio desde o princpio.
As necessidades de negcio so tipicamente mensuradas por fatores como lucro, retorno de
investimento, novos negcios e aumento no faturamento da empresa. Entretanto, esse foco
em mtricas financeiras nem sempre suficiente para determinar se um projeto, de fato, vai
adicionar valor empresa.
importante identificar os requisitos de negcio, para que se possa entender o portflio de
projetos de uma empresa como uma funo do negcio. Cada projeto de uma organizao
precisa agregar valor e trazer benefcios de diferenciao ao seu negcio. Ao se entender
essa relao, ser possvel tambm identificar fatores de falha dos projetos, alm da capacidade dos projetos em antecipar requisitos futuros de negcio e avaliar o departamento de
TI em uma organizao, de maneira a melhorar a sua performance e seus ndices de sucesso
de projetos.
Todos os projetos, desde o princpio, necessitam de uma justificativa de negcio.
Requisitos balanceados
O mtodo de Balanced Scorecard:
22
11 Reconhece que as mtricas financeiras por si s no so suficientes para mensurar a

performance da empresa.
11 Dessa forma, dar foco em mtricas financeiras pode provocar desvantagem competitiva.
O sucesso ou falha de um projeto deve ser dimensionado como uma contribuio ao plano
estratgico de negcios ou deve ser visualizado em uma mtrica de Balanced Scorecard que
confira um significado ao negcio.
O mtodo Balanced Scorecard, desenvolvido no incio dos anos 90 por David Norton e
Robert Kaplan, reconhece que as mtricas financeiras por si s no so suficientes para
mensurar a performance da empresa. Dessa forma, dar foco em mtricas financeiras pode
gerar desvantagem competitiva.
A tabela 2.2 identifica as quatro maiores perspectivas do Balanced Scorecard, mtricas e
stakeholders tpicos:
Stakeholders
Ponto de vista
Mtricas tpicas
Executivos snior,
diretores e acionistas
Viabilidade econmica
11Valor das aes
11Aumento da receita
11Aumento de lucros
Clientes externos
Valor para o cliente
11Participao de mercado
11Satisfao dos clientes
11Taxa referencial
11Reteno
Pessoas executando
o trabalho
Durao do processo e
uso eficiente de recursos
11Tempo de ciclos
CEO e arquitetos do
plano de negcios de
longo prazo
Eficincia da organizao
na adaptao a mudanas
de condies
11Adaptabilidade
11Custo de servios
11Satisfao dos funcionrios
11Compartilhamento e obteno de conhecimento

11Disponibilidade da informao
Determinando e refinando necessidades de negcio
A empresa Pass Point especializada na venda de produtos qumicos agrcolas a clientes
comerciais e fazendeiros. Recentemente, essa empresa passou por um processo de fuso
com outra empresa e, assim, expandiu seu territrio. O objetivo estratgico da nova
empresa liderar o aumento da receita no setor atravs do aumento da base de clientes,
permanecendo competitiva no ambiente de negcios e se beneficiando de sinergias de
custo planejadas como resultado da fuso das duas empresas.
O novo sistema de infraestrutura ter uma funo prioritria neste objetivo, pois vai ajudar
a eliminar a duplicidade, melhorar o foco, reduzir requisitos de recursos e utilizar o que h
de melhor em termos de tecnologia e processos.
A organizao de vendas vai melhorar as taxas de performance de vendas, como resultado
de um processo de compras bem definido, com armazenamento de informaes da contabilidade de clientes, de informaes competitivas, atribuies automticas de preo, compensao automtica e reduo de intervalos de produto.
O centro de distribuio se beneficiar do aumento do controle de gerenciamento de
estoque, da seleo automtica de rotas e mtodos de envio, e ainda de um entendimento
mais efetivo do setor de compras acerca das atividades do departamento de vendas.
A satisfao dos clientes e sua reteno so esperadas, porque os clientes tanto continuaro
a receber os melhores produtos disponveis, quanto se beneficiaro do resultado do novo
sistema, por muitas das razes dos departamentos de vendas e distribuio.
Captulo 2 - Iniciao
Tabela 2.2
Perspectivas
do Balanced
Scorecard, mtricas
e stakeholders.
Na tabela 2.4, defina as necessidades de negcio da empresa Pass Point, descrevendo como
se relacionam com as perspectivas financeiras dos clientes e do negcio.
23
Perspectiva
Necessidade de negcio
Financeira
Clientes
Negcios internos
Tabela 2.3
Perspectiva e
necessidade
de negcio.
Aprendizagem e
crescimento
Motivaes informais de projeto

11 A verdadeira motivao de um projeto pode ser mais do que uma clara justificativa de
negcios capturada em um Balanced Scorecard.

11 Um projeto pode ser motivado por fatores polticos e de poder como:
11 Prestgio.
11 Necessidade de utilizar oramento (para conseguir mais no ano subsequente).
Entretanto, capturar a verdadeira motivao de um projeto vai alm de capturar uma justificativa clara de negcios em um Balanced Scorecard. Projetos tm muitos fatores associados
sua existncia e a prpria politicagem inerente s organizaes se desdobra em outros
fatores motivadores, tais como prestgio interno e a necessidade de utilizar oramento (para
conseguir mais no ano subsequente).
Motivaes informais
Um gerente de diviso no departamento de contabilidade iniciou uma requisio para a
melhoria de um novo sistema usado por seus funcionrios.
Voc se rene com a representante dos usurios, que diz estar com dificuldades em
encontrar razes para melhorar o sistema. Ela no foi capaz de identificar onde o sistema
est falhando, em termos de performance e funcionalidade, mas acredita que as melhorias
daro ao sistema mais funcionalidades e o faro parecer mais robusto. Em uma reunio com
o time de projetos, que originalmente projetou o sistema, voc informado de que essas
melhorias no so necessrias e no estavam descritas nos requisitos iniciais de sistema
definidos pelos atuais usurios.
H um rumor de que esse departamento fez uso reduzido de seu oramento anual originalmente projetado (e alocado), e que o oramento ser perdido se no for utilizado dentro deste
ano fiscal, o que ocasionar em cortes de alocao de recursos no oramento do prximo ano.
Seus recursos de TI esto atualmente comprometidos com vrios outros projetos de alta
24
prioridade em desenvolvimento. Trabalhar nesse projeto ir requerer a realocao desses

excelentes recursos tcnicos, o que definitivamente ter impacto negativo nos projetos
existentes e em seus prazos de entrega.
1. Em sua opinio, esse projeto deve ser iniciado? Explique sua resposta.
2. Como gerente de projetos, voc conclui que esse projeto est sendo requisitado exclusivamente por uma motivao informal?
Conceito preliminar de projeto

Antes de iniciar o planejamento do projeto, garanta que uma descrio acurada e precisa
ser realizada.
11 Neste momento, a organizao executora deve fornecer uma definio conceitual do
projeto, a ser refinada at atingir um nvel de detalhamento aceitvel.
Uma definio de conceito de projeto:
11 Descreve o produto final.
11 Esclarece a funcionalidade do produto final, utilizando exemplos concretos, se necessrio.
11 Disponibiliza um foco para o planejamento do projeto.
O conceito preliminar do projeto j possui a responsabilidade de descrever o produto ou
servio a ser produzido pelo projeto, de maneira a esclarecer as funcionalidades do produto
final. Quando os requisitos so descritos em termos abstratos, so mais difceis de entender
do que quando descritos atravs de exemplos concretos de como sua funcionalidade ser
alcanada. Em resumo, o conceito preliminar do projeto tal que fornece um foco para o
planejamento do projeto em si.
Se o seu projeto orientado para pesquisa ou investigao, pode ser possvel que no haja
uma definio do conceito do projeto, criado quando h uma ideia clara para uma soluo
proposta. Alguns projetos comeam apenas com uma necessidade de negcio. Muitos
projetos, entretanto, comeam com um conceito geral de soluo, que deve ser avaliada em
termos de sua exequibilidade. S depois sero projetados, desenvolvidos e testados.
Por exemplo, requisitos de negcio podem sugerir a necessidade de um sistema mais
inteligente para os negcios. Uma definio preliminar do conceito do projeto incluiria uma
discusso dos requisitos de negcio, uma definio da funcionalidade necessria pelo novo
sistema e uma ou mais propostas de como essa funcionalidade ser obtida.
O documento de conceito preliminar do projeto deve incluir:
11 Uma avaliao do projeto proposto.
O conceito preliminar
do projeto no precisa
ser um documento de
planejamento, mas
importante que
verdadeiramente inicie
o processo de
planejamento do
projeto.
11 Impacto no tempo, no custo e nos requisitos de performance do sistema.

11 Uma discusso do potencial impacto nos recursos da empresa.
Os elementos de um documento que define o conceito do projeto precisam conter desde
a descrio inicial do produto ou servio, assim como estabelecer mtricas de sucesso
e iniciar o planejamento do projeto, como uma anlise inicial de riscos e da influncia de
aspectos como tempo, custo e qualidade nos requisitos de desempenho do sistema, alm
de uma descrio acerca da forma como os recursos da empresa sero impactados pelo
Captulo 2 - Iniciao
11 Uma anlise preliminar de riscos.
investimento que ser iniciado.

25
Para desenvolver o documento de conceito, responda as seguintes questes:
11 Qual a direo estratgica da organizao?

11 Quais as necessidades organizacionais atuais e deficincias do sistema existente?
11 Quais necessidades de negcio sero satisfeitas com o desenvolvimento do novo
sistema?
11 Que fatores tcnicos, ambientais e econmicos devem ser considerados para o
sucesso do sistema?
11 Quais os mtodos alternativos para se alcanar o mesmo objetivo?
11 Que recursos da empresa sero necessrios para suportar o desenvolvimento
do sistema?
Existem diversas questes que precisam ser endereadas no conceito preliminar do projeto.
Tais questes devem posicionar o projeto, elencar sua importncia e fornecer elementos
suficientes para discernir o que se espera do projeto no contexto organizacional. Para tanto,
importante que o conceito do projeto apresente informaes relacionando o projeto com
a direo estratgica da organizao, e o planejamento estratgico com as necessidades
organizacionais e com as deficincias dos mecanismos atuais da organizao.
Alm disso, neste ponto, j se pode iniciar uma discusso tcnica a respeito dos mtodos
de desenvolvimento do projeto, incluindo consideraes e restries de recursos, tempo e
qualidade, e a correlao de fatores de ordem tcnica, ambiental e econmica que, se satisfeitos, garantam o sucesso do produto ou servio em desenvolvimento pelo projeto.
Realizando uma anlise de requisitos de sistema

Aps definir o conceito do projeto, pode-se partir para um maior detalhamento tcnico
em termos de projeto.
11 Neste ponto, pode ser realizada uma traduo das necessidades identificadas em
requisitos tcnicos e funcionais.
Impreterivelmente, o gerente do projeto e a organizao executora precisam realizar:
11 Uma reviso dos requisitos de negcio.
11 Uma listagem dos requisitos tcnicos e funcionais.
11 A definio de critrios de sucesso para o projeto.
11 Aps todo o processo, uma reviso e verificao de requisitos com stakeholders.
Uma anlise de requisitos de sistema envolve a traduo das necessidades do negcio e dos requisitos e sua transformao em requisitos tcnicos e funcionais. Tal traduo ajuda na preparao
de um plano de projetos, na alocao de recursos e na atualizao de processos de negcio.
26
A anlise de requisitos de sistema seguida por uma reviso e verificao dos requisitos
do projeto com os stakeholders. Isso necessrio para verificar todos os requisitos e obter
qualquer informao desejada, evitando assim problemas durante o ciclo de vida do projeto.
Os seguintes tpicos sero discutidos:
11 Reviso dos requisitos de negcio;
11 Requisitos tcnicos e funcionais;
11 Critrios de sucesso;
11 Revisar e verificar requisitos.
Reviso dos requisitos de negcio

11 de responsabilidade do gerente do projeto de TI a manuteno da correlao entre
o projeto e os requisitos de negcio, para garantir que o projeto no se afaste de seu

objetivo principal.
11 Os requisitos do projeto precisam ser continuamente visitados pelo time do projeto,
durante todo o seu ciclo de vida, desde as fases de licitao de requisitos, definio
de escopo, planejamento e execuo.
O gerente de projetos de TI precisa manter a conexo entre o projeto e os requisitos de
negcio para garantir que o projeto no se afaste de seu objetivo principal. Os requisitos
de negcio devem ser revisados durante todo o ciclo de vida do projeto, desde as fases de
licitao de requisitos, definio de escopo, planejamento (atravs do fluxo de atividades) e
tambm na execuo (atravs de revises formais e informais).
Requisitos funcionais descrevem o que o sistema precisa fazer para que o seu uso
tenha sucesso.
11 Que servios so necessrios?
11 Como o sistema deve reagir a entradas particulares?
11 Como o sistema deve se comportar em situaes particulares?
11 O que o sistema no deve fazer?
Requisitos funcionais e tcnicos

Requisitos funcionais descrevem o que o sistema precisa fazer para que o seu uso tenha
sucesso. As questes que precisam ser levantadas podem incluir:
11 Que servios so necessrios?
11 Como o sistema deve reagir a entradas particulares?
11 Como o sistema deve se comportar em situaes particulares?
11 O que o sistema no deve fazer?
Requisitos tcnicos descrevem o contexto no qual o sistema deve trabalhar, incluindo o
Sistema operacional, a topologia cliente/servidor e os protocolos de rede, interfaces de
hardware, entre outros.
A figura 2.2 serve como modelo para determinar como os requisitos de negcio se relacionam
com os requisitos tcnicos e funcionais do projeto. Cada um dos requisitos pode ser listado no
cabealho apropriado. Ento se pode usar um X ou uma numerao, na matriz, para deter-
Captulo 2 - Iniciao
minar o grau de adequao do requisito tcnico e funcional ao requisito de negcio.
27
Requisitos
Tcnicos e
de Negcio
Requisitos
Funcionais
Figura 2.2
Como os requisitos
de negcio se
relacionam com os
requisitos tcnicos
e funcionais.
Regulamentaes da indstria e requisitos

11 Requisitos relacionados com regulamentaes tambm devem ser considerados
em projetos.
11 Esses requisitos, se no satisfeitos, podem colocar em risco a aceitao dos entregveis finais do projeto.
11 O gerente do projeto precisa garantir que fatores podem afetar o produto e identificar consideraes para garantir que estes so endereados.
Requisitos relacionados com regulamentaes tambm devem ser considerados em quaisquer projetos. Esses requisitos, se no satisfeitos, podem colocar em risco a aceitao dos
entregveis finais do projeto. papel do gerente de projetos pesquisar as especificidades que
podem afetar o produto e garantir que sejam endereadas na definio do escopo do projeto.
28
Alguns projetos necessitam de adequao a regulamentaes e regras governamentais. Neste

caso, necessrio garantir que toda documentao destas regulamentaes seja seguida.
Critrios de sucesso
11 As metas e os objetivos de um projeto devem ser claros.
11 Os seguintes critrios so teis para garantir a confiabilidade de um objetivo:

22 Faz sentido: enderea uma ou mais necessidades de negcio.
22 Mensurvel: operacionalmente definido de maneira que pode ser avaliado usando
mtodos quantitativos e qualitativos.
22 Gerencivel: escrito em um nvel de detalhe tal que sua execuo pode ser atribuda,
acompanhada e monitorada, com revises peridicas e deadlines (datas de finalizao).
O gerente do projeto precisa tambm garantir que os objetivos do projeto so compreendidos por todos aqueles que tiverem acesso ao plano do projeto. importante assegurar-se
de que o entendimento das metas de um projeto existe segundo um nmero de critrios
previamente definido. Cada objetivo precisa ser classificado segundo esses critrios, e a
confiabilidade do projeto pode ser associada confiabilidade dos objetivos que o compem.
Sugerimos os seguintes critrios para tal fim, mas podem existir outros, de acordo com a
necessidade de cada projeto:
11 Faz sentido: enderea uma ou mais necessidades de negcio;
11 Mensurvel: operacionalmente definido de maneira que pode ser avaliado usando
mtodos quantitativos e qualitativos;
11 Gerencivel: escrito em um nvel de detalhe tal que sua execuo pode ser atribuda,
acompanhada e monitorada, com revises peridicas e deadlines (datas de finalizao).
Identificando e verificando requisitos de negcio
Estudo de caso 1: Projeto Sistema de Converso de Cobrana (parte 1)
Voc o gerente de projetos interno da empresa Gigante Global Financeira, que orou
R$ 1 milho para contrataes internas para o projeto Sistema de Converso de Cobrana, e
a gerncia snior quer que este seja concludo em 9 meses. Sua equipe vai incluir ao menos
duas pessoas de contabilidade, vendas e TI. O principal objetivo que todas as cobranas da
empresa (seguros, emprstimos, investimentos etc.) sejam integradas em um sistema nico.
Os clientes vo receber uma comunicao da empresa e tero a opo de ver suas informaes de cobrana e realizar os pagamentos atravs da web ou via Transferncia Eletrnica de
Fundos (TEF) de diversas instituies financeiras.
Atualmente, h diversas aplicaes para cobrana, e a maioria destes sistemas roda em
mainframes IBM. Subsidirias recentemente adquiridas tambm possuem seus sistemas
prprios de cobrana, que tambm precisam ser convertidos para o novo sistema. Voc no
tem certeza do que ser envolvido na converso de dados destes sistemas.
sistema provavelmente ir requerer a compra de mil novos computadores para os usurios do novo sistema, que primariamente sero os profissionais dos setores de vendas e
contabilidade. Uma consultoria externa ir gerenciar o esforo de converso de software,
com assistncia da equipe interna. Seu patrocinador de projeto (CFO) inflexvel acerca da
concluso do projeto dentro do prazo, pois os concorrentes esto comeando a oferecer
servios similares a seus clientes, e um sistema integrado importante para aumentar os
Captulo 2 - Iniciao
Os custos de hardware e software para o novo sistema ainda no foram estimados, mas o
lucros atravs da venda casada de produtos.

29
Estudo de caso 1: Projeto Sistema de Converso de Cobrana (parte 2)

Voc recebeu informaes e requisitos adicionais para o projeto do Sistema de Converso
de Cobrana, que podem ser encontrados a seguir:
O sistema vai rodar em hardware e infraestrutura de redes j disponveis, com a exceo
da compra de novos computadores para funcionarem como clientes para os usurios do
sistema de cobrana. A Gigante Global Financeira recentemente atualizou sua infraestrutura
de TI com outro grande sistema, de modo que o novo sistema de cobrana rodar nesse
mesmo equipamento.
Os benefcios estimados do novo sistema incluem um aumento nos lucros de pelo menos
US$ 10 milhes por ano, consequncia do crescimento das vendas casadas e da conquista
de novos clientes. Estima-se que os custos sero reduzidos em US$ 2 milhes por ano, por
causa da reduo de gastos administrativos e da velocidade na obteno dos pagamentos.
O departamento de vendas foi reorganizado recentemente, e o novo VP de vendas um dos
melhores recursos disponveis no mercado.
O projeto ser iniciado em 1 de maro e finalizado em 30 de novembro.
Os usurios do novo sistema, aproximadamente 1 mil pessoas em 10 diferentes escritrios,
recebero treinamento tanto em microinformtica, para uso geral de computadores, quanto
no novo sistema.
A questo da segurana envolvendo pagamentos pela web ainda uma preocupao para
alguns clientes.
O sistema ser desenhado para minimizar a necessidade de manuteno.
O novo sistema ser fcil de usar e incluir tanto toda a funcionalidade do sistema antigo
quanto as novas caractersticas descritas na atividade de planejamento.
A partir das consideraes do caso:
1. Defina questes especficas sobre o sistema que podem ser utilizadas com os usurios finais.
2. Identifique novos requisitos de negcio.
3. Liste os requisitos tcnicos e funcionais definidos ou sugeridos neste estudo de caso.
30
4. Defina os critrios de sucesso (faz sentido, mensurvel e gerencivel) para um dos requisitos tcnicos e/ou funcionais.
Revisando e verificando requisitos

11 O objetivo de uma reviso de requisitos verificar o entendimento mtuo dos requi-
sitos com o cliente.

11 Se uma reunio face a face no possvel, ainda assim crtico identificar e obter
concordncia em diversos pontos.
11 Se uma informao estiver incompleta ou faltando, papel do gerente de projetos
endere-la antes de avanar com o projeto.
O objetivo para uma reviso de requisitos verificar o entendimento mtuo dos requisitos
com o cliente. Se uma reunio face a face no possvel, ainda assim crtico identificar e
obter concordncia em diversos pontos.
Se alguma informao estiver incompleta ou faltando, papel do gerente de projetos
levant-la antes de avanar no progresso do projeto.
Identificando papis e responsabilidades

11 Existe um grupo de stakeholders comuns a todo projeto de Tecnologia da Informao.
11 A identificao das pessoas (ou organizaes) que possuem a responsabilidade de

desempenhar estes papis fundamental para o sucesso.
11 Espera-se que o gerente do projeto, o patrocinador do projeto e o time do projeto
estejam ativamente envolvidos com o trabalho durante todo o seu ciclo de vida.
11 importante documentar at onde vai o trabalho de cada um, e em que momento o
trabalho de outro inicia em situaes tpicas de projeto no documento do escopo.
Nesta sesso, so identificados diversos participantes fundamentais em um projeto
incluindo o gerente do projeto, o patrocinador e o time de projeto. Um gerente de projeto
reconhecido como o indivduo responsvel por gerenciar o oramento, cronograma,
recursos e por se comunicar regularmente com os stakeholders. Um patrocinador de
projeto possui um papel ativo em acompanhar o progresso geral do projeto, em orientar
mudanas de cronograma e escopo, e em tomar decises finais acerca da continuidade e
finalizao do projeto.
O gerente de projetos
O gerente de projetos lidera o time que constri a soluo, e deve:
11 Estimar o projeto baseado em atividades direcionadas a negcio.

11 Trabalhar com polticas de utilizao de mtodos, ferramentas, escopo e calendrios
para garantir a exequibilidade do projeto.
11 Liderar o time para garantir que o resultado do projeto seja conseguido dentro do
cronograma, do oramento e da qualidade requeridas.
11 Motivar o time.
11 Se comunicar de forma clara e regular com o time do projeto e stakeholders.

11 Manter uma viso clara dos objetivos do projeto.
Captulo 2 - Iniciao
11 Reconhecer uma crise e ser capaz de responder apropriadamente.
31
A maioria das organizaes no possui regras para o gerenciamento de projetos. A maioria

dos gerentes de projeto no gerencia, mas administra: organizam reunies, tomam nota e
preparam minutas. Os gerentes de projeto precisam ter a habilidade e a autoridade para
tomar decises e arcar com riscos. Tal autoridade requer credibilidade e confiana dos
executivos snior e dos gerentes de negcio, algo que muitos gerentes de projeto ainda no
possuem nos dias de hoje.
O gerente de projetos lidera o time que constri a soluo. Ele precisa estar envolvido com
todas as fases do investimento, para garantir a realizao do trabalho. responsabilidade
do gerente do projeto estimar o projeto baseado em atividades direcionadas ao negcio e
administrar e motivar o time, reconhecendo crises e desenvolvendo a capacidade de mitig-las. O gerente do projeto responsvel ainda pela manuteno do foco, garantindo que os
objetivos do projeto sero atingidos e a continuidade da comunicao, tanto com o time do
projeto quanto com os stakeholders.
O gerente do projeto deve trabalhar como lder e, como tal, precisa garantir que o projeto
exequvel, trabalhando com polticas de utilizao de mtodos, ferramentas, escopo e
calendrios. A liderana do projeto precisa garantir o seu resultado, dentro do cronograma,
oramento e qualidade requeridos.
O patrocinador do projeto
11 Representa o segmento de negcio com o maior interesse na sada do projeto.
11 Para projetos em grandes empresas, o patrocinador pode ser um dos chefes de

departamento, um diretor ou um gerente de alto nvel.
11 Os patrocinadores:
22 Mantm interesse contnuo e informado sobre o progresso do projeto.
22 Participam das decises do projeto.
22 Monitoram o trabalho para encontrar sinais de descontrole no escopo e
cronograma.
22 Orientam o gerente e o time do projeto em caso de mudanas de escopo.
22 Empregam ferramentas de avaliao do projeto para ajudar o gerenciamento
do portflio.
22 Agem como um recurso final de governana para decidir quando um projeto deve
ser continuado ou suspenso.
O patrocinador do projeto representa o interesse do negcio no projeto. sua responsabilidade garantir que o resultado produzido pelo projeto esteja alinhado com a necessidade de
negcio que se vislumbra atender com o investimento. Os patrocinadores de projeto podem
ocupar as mais diversas posies em uma organizao em grandes empresas, comum
32
ocuparem responsabilidades de chefe de departamento, diretor ou de gerente de alto nvel.

Os patrocinadores precisam ter participao ativa nas decises do projeto, mantendo o interesse
contnuo no progresso do projeto. de responsabilidade do patrocinador monitorar o trabalho
e orientar o gerente do projeto em situaes crticas (como a necessidade de uma mudana de
escopo) e sinalizar quando sinais de descontrole forem identificados no escopo e cronograma.
importante que um patrocinador tenha a prtica de empregar ferramentas de avaliao do
projeto para ajudar o gerenciamento do portflio, com o objetivo de agir como um recurso
final de governana para decidir quando um projeto deve ser continuado ou suspenso.
O time de projetos
O papel do time do projeto trabalhar nos entregveis do projeto dentro do prazo
permitido e com o nvel de qualidade esperado.

11 Ter foco nos requisitos e no escopo do projeto.
11 Monitorar e gerenciar seu prprio cronograma.
11 Identificar e comunicar riscos em potencial.
O papel do time do projeto executar o trabalho planejado e, assim, trabalhar nos entregveis do projeto no prazo permitido e com o nvel de qualidade apropriado. Um time de projetos efetivo tem em cada membro algum que pensa como um gerente de projetos dentro
do escopo do trabalho sob sua responsabilidade.
importante que cada membro do time do projeto tenha a percepo de onde o seu
trabalho se encaixa no projeto como um todo, com a possibilidade de relacionar suas
atividades com os requisitos e com o escopo do projeto. Cada membro do time do projeto
precisa ter certo conhecimento em gerenciamento de projetos, para que possa monitorar e
gerenciar seu prprio cronograma, e identificar e comunicar riscos em potencial.
Criando um documento de escopo

11 Aps a identificao dos stakeholders e da documentao de cada uma de suas res-
ponsabilidades, o gerente do projeto ter elementos suficientes para descrever o que

o projeto realizar.
11 O documento de escopo contm os requisitos do projeto e estratgias para atend-los.
11 importante que o gerente do projeto utilize o documento de escopo durante todo o
seu ciclo de vida, como uma referncia para seu trabalho.
Um documento de escopo contm os requisitos e direes gerais para o projeto. usado
durante todo o projeto e, neste ponto, o objetivo do gerente do projeto deve ser conseguir
a aprovao dos stakeholders e da alta gerncia. Um documento tpico de escopo contm
objetivos do projeto, entregveis, oramento, recursos necessrios, critrios de aceitao
e sucesso, priorizaes, responsabilidades e um cronograma de marcos de alto nvel.
Uma anlise preliminar dos riscos realizada logo aps a aprovao de um documento de
escopo. Um oramento top-down criado ao se considerar todos os requisitos do projeto e
os recursos necessrios. A seguir os seguintes tpicos sero discutidos:
11 O que escopo;
11 Componentes de um documento de escopo;
11 Documentando diferenas;
11 Realizando uma anlise inicial de riscos;
O que escopo?
11 O escopo definido como a soma dos produtos e servios que sero disponibilizados
como um projeto.
11 Detalha como cada entregvel ser preparado e apresentado.
11 Ditado pelos requisitos de negcio do cliente e pela metodologia de desenvolvimento.
Captulo 2 - Iniciao
11 Criando um oramento top-down.
33
11 O documento de escopo:
22 Ajuda a estabelecer esses limites e funes, definindo uma linha de base do

projeto e seus elementos.
22 Define os requisitos do projeto, prov foco e direo, e um veculo para obteno
de aprovaes.
O escopo geralmente definido como a soma dos produtos e servios que sero disponibilizados como um projeto. Pode tambm detalhar como cada entregvel ser preparado e
apresentado. O escopo normalmente ditado pelos requisitos de negcio do cliente e pela
metodologia de desenvolvimento.
Definir o escopo significa chegar a um entendimento comum dos maiores delimitadores
do projeto e das funes de negcio que o projeto vai incorporar. O documento de escopo
ajuda a estabelecer esses limites e funes, define uma linha de base do projeto e vrios
elementos. Sem essa linha de base, o esforo do trabalho, o tempo para sua finalizao e
os critrios de sucesso para a avaliao final poderiam ser expandidos indefinidamente,
tomando propores irrealistas e no gerenciveis.
A falha na definio do escopo, no comeo de um projeto, impossibilita ao gerente a determinao dos critrios de sucesso, custo, tempo ou recursos necessrios para a finalizao
do projeto.
Componentes de um documento de escopo

11 Existem componentes tpicos de um documento de escopo que precisam estar
presentes para que o documento tenha fora suficiente para ser utilizado
como referncia .
11 Use a lista a seguir como um checklist da maioria desses componentes:
22 Objetivos do projeto o que o projeto deseja alcanar.
22 Entregveis o que vai existir que no existia antes.
22 Limites:
33 O que ser e o que no ser includo.
33 O que foi pr-determinado versus o que pode ser escolhido por ocasio
do projeto.
22 Critrios de sucesso o que necessita ser demonstrado antes que o projeto seja
considerado um sucesso.
22 Prioridades priorizar custo, cronograma e escopo.
22 Riscos e consideraes.
22 Oramento geral.
22 Responsabilidades uma lista das pessoas com autoridade para tomada de
deciso e seus papis.
22 Cronograma de marcos de alto nvel para os principais entregveis, revises e
finalizao do projeto.
Um documento de escopo tipicamente define:

11 Objetivos do projeto: o que o projeto deseja alcanar em cada uma de suas fases. No se
trata apenas do resultado final, mas pode detalhar aspectos como atualizao de ativos organizacionais, posicionamento estratgico, desenvolvimento de fornecedores, entre outros;
34
Um documento de
escopo define os
requisitos do projeto,
prov foco e direo,
e um veculo para
obteno de
aprovaes.
11 Entregveis: o que vai existir que no existia antes, em termos concretos. Pode ser um
documento, um script; um trecho de cdigo, um ambiente etc.;
11 Limites: o que ser e o que no ser includo de fundamental importncia garantir que
as expectativas estejam bem definidas no documento de escopo;
11 O que foi pr-determinado versus o que pode ser escolhido por ocasio do projeto.
Exemplo: o pacote a ser utilizado no desenvolvimento foi pr-determinado e o gerente de
projetos precisa utilizar um certo grupo de pessoas;
11 Critrios de sucesso o que necessita ser demonstrado antes que o projeto seja considerado um sucesso;
11 Prioridades: priorizar custo, cronograma e/ou escopo;
11 Riscos e consideraes: j hora de levantar aspectos que podem influenciar o projeto
negativamente ou positivamente. importante estabelecer o entendimento comum
desses aspectos;
11 Oramento geral;
11 Responsabilidades: os stakeholders, as pessoas com autoridade para tomada de deciso
e seus papis;
Um cronograma de marcos de alto nvel para os principais entregveis, revises e finalizao
do projeto.
Documentando diferenas
11 A declarao de trabalho do projeto descreve o prazo, custo e a qualidade do projeto
em termos de requisitos e limites.

11 Deve incluir o que foi discutido na fase de escopo e englobar tudo o que possa dar
foco ao projeto.
11 Um documento de escopo diferente de uma estrutura analtica de projeto (EAP ou
WBS) ou de um plano de projetos, pois incorpora elementos de mais alto nvel de
cada um desses documentos.
22 A EAP e o plano de projetos so desenvolvidos a partir do documento de escopo.
22 Cada um dos documentos subsequentes, desenvolvidos medida que o projeto
progride, uma expanso da informao contida no documento de escopo.
Algumas vezes, um documento de escopo inclui apenas os limites do projeto, mas neste
curso propomos que ele seja mais abrangente, incluindo todos os itens discutidos na fase de
escopo e englobando tudo o que possa agregar valor e conferir foco ao projeto.
A declarao de trabalho do projeto (statement of work) normalmente descreve o tempo,
custo e a qualidade do projeto em termos de requisitos e limites. Neste curso, a declarao
de trabalho do projeto entendida como um subconjunto do documento do escopo.
Da mesma forma, um documento de escopo diferente de uma Estrutura Analtica de
incorpora os elementos de mais alto nvel de cada um desses documentos. A EAP e o plano
de projetos so inicialmente desenvolvidos a partir das informaes contidas no documento
de escopo. Cada um dos documentos subsequentes, desenvolvidos medida que o projeto
progride, uma expanso da informao contida no documento de escopo.
Um documento de escopo pode incluir elementos de alto nvel de um plano para esclarecer
requisitos de tempo e custo, mas tipicamente no inclui a informao num nvel de detalha-
Captulo 2 - Iniciao
Projetos (EAP) ou Work Breakdown Structure (WBS) ou de um plano de projetos, pois
mento requerido por uma declarao de trabalho do projeto ou de uma EAP.

35
Realizando uma anlise preliminar de riscos

11 Todos os riscos tcnicos e de negcio possveis devem ser elencados, com a avaliao
de seus efeitos no projeto.

11 A anlise preliminar de riscos ajudar no planejamento de negcios que pode ser
necessrio por causa do projeto.
Com o objetivo de direcionar o processo de planejamento e no entendimento do projeto em
termos estratgicos e organizacionais, necessria a realizao de uma anlise preliminar
de riscos. No se trata de uma anlise de riscos extremamente detalhada: neste ponto,
importante elencar, sobretudo, riscos tcnicos e de negcio que possam influenciar a continuidade ou o cumprimento do ciclo de vida do projeto. importante tambm, se possvel,
adicionar ao documento de escopo e avaliar os possveis efeitos desses riscos no projeto.
Criando um oramento top-down

11 Um oramento top-down um objetivo de custos baseado no negcio, nos requisitos
funcionais e em consideraes de recursos.

11 Deve incluir fundos adicionais como contingncia a riscos.
11 Tambm chamado de oramento de ordem de magnitude, deve servir como referncia ao planejamento.
11 Pode ser desenvolvido baseado em experincias passadas.
Nesse ponto, pode-se tambm incluir uma ideia geral acerca do custo do projeto, atravs
de um oramento top-down. Esse oramento no necessariamente uma linha de base de
custos, mas um nmero de ordem de magnitude que pode ser obtido com base em experincias passadas com projetos parecidos , que servir para direcionar o planejamento do
projeto, e impedir que esse processo de planejamento estime um trabalho que no atenda
de fato aos objetivos de negcio da organizao ou realize um trabalho desnecessrio. Se
possvel, o oramento top-down j deve incluir fundos adicionais, como contingncia a riscos
previamente elencados.
Obtendo consenso e aprovao dos stakeholders

11 Aps a elaborao do documento do escopo, importante obter a aprovao
dos stakeholders.
11 O consenso e a aprovao garantem a sustentabilidade do projeto:
22 Aliando as expectativas dos stakeholders em relao ao que ser realizado.
22 Auxiliando na compreenso do trabalho.
22 Servindo como uma referncia para resoluo de conflitos.
A obteno do consenso e da aprovao dos stakeholders em respeito ao documento de escopo
36
um passo importante que deve ser concludo antes da iniciao do planejamento do projeto.
A obteno do consenso ajuda no progresso sustentvel do projeto, pois alia as agendas dos
stakeholders com o projeto e impede que se criem obstculos para o gerente de projetos.
A compreenso detalhada do documento do escopo, da estrutura de gerenciamento da empresa
e da estratgia de negcios ajudar na obteno do consenso da maioria dos stakeholders.
Importncia do consenso
11 A obteno de consenso garante que os stakeholders trabalhem na mesma direo,
cumprindo os objetivos do projeto.

11 importante garantir que os principais afetados pelo projeto possuam a mesma
percepo do trabalho, para evitar a oposio da alta gerncia.
22 O consenso deve ser concreto e registrado no documento de escopo do projeto.
22 Sem um acordo, requisitos adicionais podem complementar o escopo podendo
trazer riscos em termos de custo, qualidade e cronograma.
A falta de consenso faz com que os diversos stakeholders trabalhem em direes opostas.
Essa oposio pode ser no intencional, e acontece especialmente quando os stakeholders
possuem percepes diferentes do que o projeto deve fazer e, sendo assim, da forma como
eles devem apoi-lo. Os stakeholders que no apoiam o projeto podem sabot-lo de diversas
formas: minando a autoridade do gerente de projeto, dificultando a alocao de recursos,
adicionando novos requisitos ou dificultando a aprovao de entregveis do projeto.
O gerente do projeto precisa entender que, no momento em que os stakeholders dizem que
apoiam o projeto, deve haver um acordo concreto e documentado do escopo do projeto.
Sem um acordo, requisitos adicionais podem ser trazidos ao escopo mais tarde o que certamente impactar o custo, a qualidade e o cronograma do projeto.
Se a obteno do consenso entre a gerncia do projeto e os stakeholders de um projeto no
ocorre, o esforo do projeto pode aumentar exponencialmente e a habilidade do gerente
de projeto de cumprir os prazos, requisitos de qualidade e especificaes dos entregveis
ser questionada, pois depende tanto do gerenciamento em si quanto da concordncia dos
stakeholders a respeito de cada componente do documento do escopo.
Sendo assim, crucial para a sade do projeto que todos os stakeholders atestem sua concordncia formal, uma vez que o consenso foi obtido no documento de escopo.
Identificando estratgias para obter o consenso

11 Uma deciso em consenso aquela que todo o grupo concorda em apoiar, embora
no necessariamente todos a tenham escolhido como sua primeira escolha.

11 A construo do consenso requer informaes slidas de escopo e um entendimento
claro das influncias organizacionais que motivaro os stakeholders a apoiar o projeto.
22 Tente envolver todos os principais stakeholders.
22 Procure por diferenas de opinio.
22 Escute cada indivduo e considere seus pontos de vista com cuidado antes
de prosseguir.
22 Identifique onde voc pode ser flexvel; se o documento de escopo precisa ser
ajustado, em que pontos voc considera mais fcil realizar ajustes.
22 Obtenha assinaturas do documento de escopo.

Uma deciso em consenso aquela que todo o grupo concorda em apoiar, embora no
necessariamente todos a tenham escolhido como sua primeira escolha. Dessa forma, a
relevncia no est na obteno de um consentimento unnime ou conseguido pelo voto
da maioria, mas atravs de um processo aberto de comunicao onde todos os problemas
potenciais so levantados.
Captulo 2 - Iniciao
22 Apresente a informao de maneira clara, concisa e convincente.
37
A construo do consenso requer informaes de escopo slidas e um entendimento

claro das influncias organizacionais que motivaro os stakeholders a apoiar o projeto.
Na maioria das vezes, no fcil obter o consenso, mas o seu processo de construo,
por envolver recursos de todas as partes envolvidas, aumenta a efetividade da tomada de
deciso futura no projeto.
Estratgias para consenso
11 Tente envolver os principais stakeholders;
11 Procure por diferenas de opinio:
22 D tempo para que as pessoas compartilhem suas vises, preocupaes e diferenas
de opinio;
22 Defina claramente e especificamente onde esto as diferenas.
11 Escute cada indivduo e considere seus pontos de vista com cuidado antes de prosseguir;
11 Identifique onde voc pode ser flexvel. Se o documento de escopo precisa ser ajustado,
em que pontos voc considera mais fcil realizar ajustes?
11 Apresente a informao de uma maneira clara e concisa, mas tambm convincente:
22 O consenso normalmente obtido de forma melhor quando se considera uma deciso
especfica de projeto;
22 Crie um documento fcil de ler, que capture o objetivo do projeto proposto;
22 Apresente o escopo do projeto aos stakeholders e patrocinadores usando uma representao visual dos objetivos do projeto, requisitos de negcio e outros componentes.
11 Obtenha assinaturas do documento de escopo:
22 Isso deve representar um marco chave no processo do projeto;
No queira obter concordncia mais rapidamente do que necessrio analise antes se os
requisitos fazem sentido, so gerenciveis e mensurveis.
38
3
Desenvolver uma Estrutura Analtica do Projeto (EAP ou WBS). Estabelecer marcos de
projeto realistas e mensurveis, alm de definir critrios de entrada e sada para eles.
Identificar e priorizar riscos de projeto. Criar uma estimativa de esforo, tempo,
e custos do projeto.
conceitos
Detalhamento do escopo, EAP e marcos de projeto. Riscos de projetos. Restrio tripla.
Exerccios de nivelamento
1. Em um projeto de TI, s necessrio realizar atividades de planejamento uma vez.
(a) Verdadeiro
(b) Falso
2. O que uma Estrutura Analtica do Projeto?
3. Um projeto deve continuar mesmo que existam riscos associados a ele.

(a) Verdadeiro
(b) Falso
4. Que fatores devem ser considerados ao se estimar os custos de um projeto?
5. Liste duas ferramentas para elaborar o cronograma de um projeto.
6. Como se deve monitorar a qualidade de um projeto em realizao?
Captulo 3 - Planejamento
objetivos
Planejamento
39
Introduo
Nesta sesso, ser estudada a fase de planejamento de um projeto de TI. A Estrutura Analtica do Projeto (EAP) ser apresentada como uma forma de detalhar o projeto inteiro em
diferentes funes e atividades. O gerenciamento de riscos ser discutido para identificar
e priorizar riscos, avaliar seus efeitos e desenvolver mtodos para reduzir sua severidade.
Estudaremos elementos como esforo, tempo, custo e a criao de um cronograma de
projeto. Tcnicas para criar uma estimativa de custos sero usadas para a criao de um
oramento para o projeto em sua totalidade.
Alm disso, sero apresentadas formas de gerenciar e construir um time de projetos
eficiente desde a seleo de fornecedores resoluo de problemas de projeto. A seguir, o
aluno aprender a construir um plano de comunicaes para um fluxo estvel da informao entre os stakeholders, usurios e clientes, alm dos prprios membros do time de
projetos. O gerenciamento da qualidade e o monitoramento so discutidos para garantir
que os entregveis atendem aos requisitos iniciais. A ltima parte do captulo familiariza o
estudante com os diferentes componentes do plano de gerenciamento do projeto, e a
preparao de um plano de gerenciamento de projetos eficiente.
A figura 3.1 ilustra a definio do escopo e como ela se encaixa no processo de
gerenciamento do projeto.
1. Iniciao
2. Planejamento
3. Execuo
5. Enceramento
Figura 3.1
Definio do
escopo.
Planejamento
11 Funo central do gerenciamento de projetos.
11 No deve ser terceirizado ou delegado.

11 No uma atividade a ser realizada uma nica vez.
22 medida que o projeto evolui, as revises podem ser dirigidas por diversos
fatores.
11 Serve a cinco funes principais:
22 Mapear necessidades em tarefas gerenciveis.

22 Definir recursos necessrios.
22 Coordenar o time de projetos.
22 Avaliar riscos de projeto.
22 Identificar problemas.
O planejamento a funo central do gerenciamento de projetos e no deve ser terceirizado
ou delegado, muito embora a participao dos envolvidos seja importante. Para projetos
complexos de TI, o planejamento e o esforo realizados por trs do planejamento de requisitos so to importantes quanto o plano resultante.
40
O planejamento no uma atividade que ser realizada uma nica vez; planos precisam ser
continuamente revisados ao longo da execuo do projeto. medida que o projeto evolui,
as revises podem ser dirigidas por fatores como mudanas nos requisitos ou no ambiente
do projeto, resultados de teste, estimativas que precisam de ajuste e disponibilidade de
recursos. Nesta sesso discutiremos o processo de planejamento.
O planejamento serve a cinco funes principais, descritas na tabela 3.1:
Funo
Descrio
Mapear necessidades em
tarefas gerenciveis
O objetivo do estgio de planejamento determinar como o projeto vai

satisfazer as necessidades de negcio e os requisitos de projeto que foram
inicialmente definidos durante o estgio de escopo.
Definir recursos necessrios
Planos detalhados permitem que o gerente de projetos determine que pessoas,

equipamento e facilidades sero necessrios durante a durao do projeto.
Coordenao do trabalho do
time de projetos
Normalmente, as atividades de um projeto so realizadas por diferentes

pessoas trabalhando de maneira semi-independente e paralela. O planejamento deve permitir a coordenao atravs da determinao de quem est
fazendo o qu e quando.
Avaliar riscos de projeto
Enquanto alguns riscos podem ser identificados durante a determinao do

escopo do projeto, muitos outros aparecem durante o desenvolvimento de um
plano detalhado. O conhecimento desses riscos permite ao gerente do projeto
perceb-los rapidamente caso apaream, e se prepare para endere-los.
Sinalizar problemas que

apaream
Alm da identificao formal de riscos, possvel tambm identific-los

atravs de desvios do planejamento inicial. Planos no so uma estrutura fixa
s quais devemos aderir literalmente, mas servem ao gerente de projeto como
uma expectativa inicial e base de comparao. Se o projeto no estiver satisfazendo as expectativas iniciais, ento uma correo apropriada deve ser feita.
Viso geral do processo de planejamento:

11 O processo de planejamento deve ser iniciado o quanto antes em um projeto.
11 Planejar inclui um grande nmero de atividades.

22 Objetivo de detalhar o trabalho em partes menores e mais gerenciveis, para reconhecer os marcos crticos de performance durante o caminho.
Planejar passa pelas seguintes atividades: definir um projeto da reunio de abertura at o
encerramento, detalhar o trabalho em partes menores e mais gerenciveis e reconhecer os
marcos de performance crticos durante o caminho. Detalhar o trabalho em partes menores
facilita o processo de determinao das necessidades de recurso, coordenao, identificao de riscos e percepo de desvios.
A figura 3.2 mostra o planejamento como um mapeamento dos requisitos de negcio
(necessidade) e requisitos de projeto (escopo) em atividades de trabalho detalhadas. Se a
necessidade descreve o porqu de o projeto estar sendo realizado e o escopo descreve o
que necessrio para o projeto, ento as atividades de planejamento descrevem como os
requisitos sero satisfeitos.
Tabela 3.1
Cinco funes
principais do
planejamento.
41
Riscos
Necessidades
Escopo
Trabalho
Estimar
Alocar
Figura 3.2
A figura tambm mostra dois elementos que tambm esto includos no escopo, que incluem
avaliao de riscos e estimativa de custos e durao. Eles so considerados em um nvel mais
alto, ou baseados em informao top-down, durante o estgio de escopo. Durante o planejamento, riscos e estimativas so detalhados, baseados em atividades especficas de projeto. O
termo alocar, nesse diagrama, usado para denotar a atribuio e o agendamento de
trabalho. As setas no diagrama indicam que riscos afetam as estimativas e que o esforo
estimado e o custo para trabalho precisam ser alocados para as pessoas atravs do tempo,
assim como equipamento e facilidades. A alocao pode causar conflitos entre requisitos de
custos, durao e qualidade, que ento demandariam uma reviso de escopo.
Esse diagrama ser revisitado de uma maneira um pouco diferente mais adiante na fase de
planejamento, para destacar a relao entre algumas atividades especficas de planejamento.
Criando uma Estrutura Analtica do Projeto

11 Para se iniciar o processo de planejamento, necessrio referenciar o documento
de escopo e iniciar um processo de anlise de atividades para atender aos objetivos

do projeto.
11 Essas atividades devem ser genricas o suficiente para garantir o entendimento
do trabalho.
22 Elas sero posteriormente detalhadas para gerar o cronograma do projeto.
11 Essas atividades referenciadas aqui como pacotes de trabalho, quando agrupadas,
geraro a EAP.
O primeiro passo no planejamento de um projeto examinar o documento de escopo e
criar um plano de trabalho para identificar e analisar as atividades envolvidas na obteno
de objetivos do projeto. Essas atividades so posteriormente detalhadas em funes e atividades menores e mais gerenciveis do que aquelas descritas na EAP. A Estrutura Analtica
do Projeto uma estrutura hierrquica de vrias funes e atividades, e assiste na criao
do cronograma do projeto atravs da atribuio de funes e atividades a vrios departa-
42
mentos, mas tambm no gerenciamento dessas atividades.
O que uma EAP?

11 Uma EAP uma decomposio hierrquica e uma organizao de pacotes de trabalho
que precisam ser realizados de maneira a se atingir os objetivos do projeto.
11 A EAP precisa auxiliar no planejamento, atribuio e gerenciamento do projeto.
Atividade 1.3
Funo 2
Atividade 2.1
A EAP uma decomposio hierrquica e uma organizao de atividades que precisam ser
feitas de maneira a se atingir os objetivos

do projeto
Atividade
2.2 (figura 3.3). A organizao e o nvel de
detalhe dos marcos do projeto e dos pacotes de trabalho devem auxiliar na estimativa, na
Atividade
2.3 Para conseguir isso, as atividades da
atribuio de trabalho e no gerenciamento
contnuo.
EAP precisam respeitar o critrio descrito na tabela 3.2.
1. Projeto
1.1 Marco de Projeto
Figura 3.3
Estrutura Analtica
do Projeto.
1.1.1 Pacote de Trabalho
Critrio
Descrio
Objetivo nico
e independente
Para incentivar o auto-gerenciamento de recursos humanos ou de subgrupos do

time de projetos, cada atividade deve ser definida at um nvel de detalhe tal que
possa ser completada sem a necessidade de coordenao ativa da performance de
outras atividades. H muitas dependncias entre atividades de projeto, mas essas
so melhor gerenciadas atravs do detalhamento do trabalho em subconjuntos
semi-independentes.
Durao especfica
As atividades no podem ser abertas, ou a durao do trabalho ser prolongada. A

durao tambm d uma ideia da qualidade esperada do entregvel.
Entregveis claramente
compreendidos
A atividade deve produzir um entregvel que seja claramente entendido pelas

pessoas que realizaro o trabalho. O entregvel pode ser uma deciso, prottipo,
arquitetura, especificao, documento, teste etc.
Familiaridade
A maioria dos projetos de desenvolvimento envolve a criao de algo novo. O trabalho que leva a essa criao, entretanto, j foi realizado anteriormente (talvez no
exatamente da mesma forma que dever ser realizado no novo projeto). A familiaridade com atividades detalhadas facilita a estimativa e a atribuio do trabalho.
A EAP uma forma de estruturar as atividades de um projeto.
Usos e importncia da EAP

11 A importncia da EAP est no fato de ser uma forma de organizar as tarefas para sim-
plificar o trabalho envolvido na estimativa, cronograma, coordenao e reviso.

11 Possibilita o detalhamento do projeto em fases subsequentes.
11 Detalhar o trabalho em atividades menores por meio da identificao de tarefas
necessrias ajuda a tornar os objetivos de projeto gerenciveis.
11 Indiretamente, todos os planos so baseados nas atividades identificadas na EAP.
11 Diretamente, podemos citar as seguintes atividades de planejamento que dependem
da EAP:
22 Cronograma do projeto.
22 Alocao de recursos.
22 Oramento detalhado.
Tabela 3.2
Critrios.
43
Como foi mencionado, detalhar o trabalho em atividades menores por meio da identificao
de tarefas necessrias ajuda a tornar os objetivos de projeto gerenciveis. Os projetos
podem facilmente ter algumas centenas de atividades para ser completo, e mesmo assim
uma simples lista dessas atividades j pode ser difcil de gerenciar. A EAP uma forma de
organizar as tarefas para simplificar o trabalho envolvido na estimativa, cronograma, coordenao e reviso.
Indiretamente, todos os planos so baseados nas atividades identificadas na EAP. Diretamente,
podemos citar as seguintes atividades de planejamento que dependem da EAP:
11 Cronograma do projeto;
11 Alocao de recursos;
11 Oramento detalhado.
Desenvolvendo uma EAP

11 Os seguintes passos descrevem um processo para desenvolver uma EAP:
22 A partir do documento de escopo, identifique os principais objetivos de negcio

do projeto.
22 Ainda no documento de escopo, identifique os requisitos funcionais necessrios
para atingir os objetivos do projeto.
22 Identifique as principais atividades necessrias para satisfazer os requisitos
funcionais.
33 Para tornar o projeto mais gerencivel e garantir que todas as tarefas relevantes foram includas, inclua um nvel intermedirio de detalhamento.
11 Subdivida os principais pacotes de trabalho em atividades menores que reflitam
como o trabalho ser feito.
11 Faa uma estrutura hierrquica, criando tantas camadas quanto forem necessrias
para detalhar o trabalho em um nvel tal que possibilite:
22 Estimar e agendar o trabalho.
22 Atribuir o trabalho para um indivduo ou grupo.
22 Monitorar e comunicar o progresso do trabalho.
Propomos a seguir um processo (passo a passo) que pode ajudar o desenvolvimento de uma
EAP para um projeto. Os seguintes passos descrevem um processo que pode ser seguido
para o desenvolvimento de uma EAP:
1. A partir do documento de escopo, identifique os principais objetivos de negcio do
projeto so os objetivos de negcio que norteiam o desenvolvimento da EAP e deter-
minam os Marcos do Projeto.
44
2. Ainda no documento de escopo, identifique requisitos funcionais necessrios para alcanar

tais Marcos do Projeto, ou objetivos do projeto os requisitos funcionais devem ser tais que
possam ser traduzidos ou mapeados em atividades realizveis e pacotes de trabalho.
3. Alm disso, identifique as principais atividades necessrias para satisfazer os requisitos funcionais. Para tornar o projeto mais gerencivel e garantir que todas as tarefas
relevantes foram includas, normalmente til incluir um nvel intermedirio de detalhamento; no objetivo da EAP conter as atividades do cronograma, mas um conjunto de
entregveis que, se detalhados, originaro a maior parte dessas atividades.
A anlise de riscos
tambm comumente
orientada pelas tarefas
detalhadas definidas
na EAP.
4. Subdivida as principais tarefas em atividades menores que reflitam como o trabalho

ocorrer.
5. Elabore uma estrutura hierrquica, criando as camadas necessrias para detalhar o
trabalho em peas menores, em um nvel de detalhamento suficiente para se fazer o
seguinte:
a. Estimar e agendar o trabalho;
b. Atribuir o trabalho para um indivduo ou grupo;
c. Monitorar e comunicar o progresso do trabalho.
Realizando o gerenciamento de riscos

11 Um passo importante no processo de planejamento do projeto revisitar os riscos
identificados na fase de definio de escopo e realizar um levantamento mais detalhado, considerando os entregveis do projeto.
11 A anlise de riscos importante para estimar a probabilidade de concluso de
um projeto.
11 O planejamento dos riscos de um projeto envolve identificao, quantificao, controle e interao desses riscos com o projeto como um todo.
O gerenciamento de riscos realizado para identificar todos os riscos associados ao projeto
e priorizar e analisar o efeito de cada risco no projeto. O levantamento dos riscos uma
parte importante da fase de planejamento e auxilia tanto na reduo das incertezas associadas ao projeto quanto com a obteno de suporte da gerncia. O gerenciamento de riscos
envolve a identificao, quantificao, controle e interao. Planos devem ser implementados nesse estgio para reduzir o impacto de riscos que no podem ser evitados e para
gerenci-los adequadamente durante o tempo de vida do projeto.
A anlise de riscos tambm revela a probabilidade de concluir o projeto. normalmente
uma atribuio do patrocinador do projeto e da gerncia cancelar ou prosseguir com o
projeto, levando em considerao a anlise de riscos realizada.
Por que gerenciar riscos?

11 O gerenciamento de riscos necessrio porque os projetos envolvem incertezas.
11 Embora no elimine as incertezas, o gerenciamento de riscos garante que elas so consideradas e habilita o gerente do projeto a reconhecer e tratar os efeitos negativos.
11 O gerenciamento de riscos incorpora os seguintes benefcios ao projeto:
22 Melhora a visibilidade do projeto, pois possibilita alertar a gerncia de quaisquer
fatores que possam interferir no sucesso do projeto.
22 Reduz o nvel de incertezas por meio do desenvolvimento de estratgias alterna22 Facilita a transferncia de conhecimento atravs da organizao e documentao
de experincias.
O gerenciamento de riscos est atrelado ao grau de incerteza inerente aos empreendimentos
e investimentos que geram projetos. Dependendo do quo incerto o futuro de um projeto,
essas incertezas podem levar a estouros de cronograma e custos, e ao no atendimento
de requisitos. O gerenciamento de riscos no vai eliminar as incertezas, mas vai habilitar o
gerente de projetos a reconhecer e tratar os efeitos negativos de uma dada incerteza.
tivas para os desafios do projeto.
45
importante que o gerente veja o processo de gerenciamento de riscos como um fator

incorporador de benefcios ao projeto, pois melhora a visibilidade do projeto, possibilitando
alertar a gerncia de fatores que possam interferir no sucesso do que foi planejdo. Alm
disso, como contm um processo de reduo de incertezas, o gerenciamento de riscos
invariavelmente desenvolve estratgias alternativas para os desafios do projeto, facilitando
a transferncia de conhecimento atravs da organizao e documentao de experincias.
Processo de gerenciamento de riscos

11 O gerenciamento de riscos um processo contnuo de identificar, quantificar e
controlar fatores de risco potenciais, que pode impactar a habilidade de satisfazer

requisitos de projeto como tempo, custo e qualidade.
O gerenciamento de riscos no cessa em nenhum momento do desenvolvimento de um
projeto. A todo instante, o time e o gerente do projeto precisam estar alertas ao ambiente
do projeto e de negcios, de maneira que possam continuamente identificar, quantificar e
controlar fatores de risco potenciais. Esse processo de identificao, quantificao e controle
detalhado na tabela 3.3, e pode impactar a habilidade de satisfazer requisitos de projeto como
tempo, custo e qualidade, assim como outros objetivos de negcio mais genricos.
Ao
Descrio
Identificar
Use o seu conhecimento como gerente de projetos a respeito dos

recursos e determine em que situaes eles poderiam falhar em satisfazer os requisitos. Identifique, nesse sentido, tanto riscos internos
quanto externos.
Quantificar
Quantifique potenciais problemas relacionados a escopo, custo, tempo,

qualidade ou pessoas, baseados no risco (probabilidade de acontecer) e
severidade (se, de fato, acontecerem).
Controlar
Use estratgias para reduzir o impacto dos riscos. Considere mudar sensivelmente alguns requisitos e planos. Documente formalmente e obtenha
aprovaes para se certificar de que o controle um processo recorrente
(evitando o chamado scope creep).
Iterar
Realize o gerenciamento de riscos regularmente ao longo do projeto:

Revise o progresso geral do projeto;
Identifique o progresso relacionado a riscos existentes, e revise a quantificao destes;
Identifique novos riscos e os quantifique;
Desenvolva controle e, quando apropriado, revise requisitos e/ou planos.
Identificao de riscos
11 Clientes, tecnologias, recursos, estimativas e fatores organizacionais podem ser
geradores de riscos.
46
11 Riscos podem ser identificados de forma top-down ou bottom-up.

Existem diversas fontes de risco, como clientes, tecnologias, recursos, estimativas e fatores
organizacionais, como componentes que adicionam riscos ao projeto. Riscos podem ser
identificados tanto de forma top-down quanto bottom-up, como mostra a tabela 3.4:
Figura 3,3
Identificao,
quantificao e
controle.
Descrio
Exemplo
Top-down
Liste os requisitos do projeto

e possveis problemas para
satisfaz-los.
Requisitos: dados do sistema antigo.
Liste as possveis causas de

risco e determine como o
projeto seria exposto a esses
fatores.
Possvel causa: time tcnico pouco experiente.
Bottom-up
Possveis falhas: estruturas de dados

inconsistentes.
Exposio: pode no ser possvel mapear

campos de dados de maneira correta.
Quantificao de riscos
11 Aps identificar os riscos, importante atribuir notas para a sua gravidade, o que
quantifica potenciais danos ao projeto caso o risco ocorra.

11 Alm da gravidade (severidade), a probabilidade de ocorrncia de cada risco tambm
deve ser quantificada.
11 A combinao da severidade com a probabilidade define o grau de importncia do risco.
22 Um risco severo que possua baixa probabilidade de ocorrncia deve ser monitorado.
22 Normalmente no vale a pena investir em estratgias extensivas e caras para
control-lo.
Atribuir notas para a severidade de riscos quantifica os potenciais danos ao projeto, caso o
risco acontea. Atribuir notas para a severidade de riscos quantifica os potenciais danos ao
projeto, caso o risco se concretize. Nem todos os riscos so criados igualmente, e o foco deve
ser mantido nos mais importantes. Avaliar a severidade de um risco til para a priorizao e
entendimento dos riscos que necessitam de ao para reduzir seu impacto potencial.
A probabilidade de ocorrncia de cada risco tambm deve ser quantificada. A combinao
da severidade com a probabilidade define a importncia do risco. Um risco muito severo que
possua uma baixa probabilidade de ocorrncia deve ser monitorado, mas provavelmente
no vale a pena investir em estratgias extensivas e caras para control-lo.
Uma escala de 1 a 5 pontos (onde 5 o resultado mais severo) geralmente adequada para
ranquear e decidir prioridades. Para atribuir um nvel de severidade a um dado risco, cada
nvel precisa de uma definio do critrio em uso para que o nvel identificado seja atingido.
Uma escala similar deve ser suficiente para quantificar a probabilidade.
Controlando riscos
11 Em um projeto, os riscos vo existir, com ou sem planejamento.
11 A chave est em gerenciar os riscos de maneira eficiente.

11 O planejamento para minimizar um risco passa pela escolha de uma das seguintes
estratgias:
22 Estratgias alternativas: mudar a abordagem inicialmente planejada para o projeto.
22 Planejamento de contingncia: definir passos se um determinado risco ocorrer.
22 Fornecedores: obter bens e servios fora da organizao executora do projeto.
11 Em um projeto bem gerenciado, os riscos diminuem medida que o projeto se aproxima do seu encerramento.
22 Na verdade, um aumento na probabilidade ou severidade de um risco no ponto de
implantao deve ser interpretado como um sinal de alerta para o negcio.
Tabela 3.4
Como identificar
riscos.
Tipo
47
Todo profissional com experincia em projetos sabe que, em todo e qualquer projeto,
importante controlar os riscos, que existiro com ou sem planejamento. A chave est em
gerenciar os riscos de maneira eficiente identificando-os, quantificando-os e garantindo
que no saiam do controle. Um processo de planejamento para minimizar um risco passa
pela escolha de uma das seguintes estratgias:
11 Estratgias alternativas: mudar a abordagem inicialmente planejada para o projeto;
11 Planejamento de contingncia: definir passos se um determinado risco ocorrer;
11 Fornecedores: obter bens e servios fora da organizao executora do projeto.
Em um projeto bem gerenciado, os riscos diminuem medida que o projeto se aproxima
da fase de implantao. Na verdade, um aumento na probabilidade ou severidade de um
risco no ponto de implantao deve ser interpretado como um sinal de alerta para toda a
gerncia de negcios envolvida com o projeto.
Probabilidade de concluso de um projeto

A probabilidade de se concluir um projeto pode ser estimada considerando os seguintes
fatores de risco:
11 Probabilidade da ocorrncia dos riscos.
11 Severidade dos riscos caso ocorram.
11 Eficincia dos mtodos de contingncia caso seja necessrio implement-los.
possvel, atravs de mtodos estatsticos, obter a probabilidade de concluso de um
projeto. Para tanto, preciso considerar a quantidade de riscos de um projeto, a importncia desses riscos e o modo como a organizao executora vai trat-los. A partir dessas
aes, necessrio realizar uma anlise da probabilidade e da severidade dos riscos, caso
eles ocorram, e quantificar a eficincia dos mtodos de contingncia de riscos, caso seja
necessrio implement-los. Mtodos como a Simulao de Monte Carlo podem ser empregados para se estimar a probabilidade de concluso do projeto, e estipular a ao a ser
tomada caso os nmeros obtidos no sejam satisfatrios.
Desenvolvendo estimativas de esforo, tempo e custos

11 Aps o detalhamento dos riscos do projeto, aliado declarao de escopo e EAP, o
gerente do projeto conta com uma ferramenta que:

22 Alimentar as estimativas subsequentes.
22 Facilitar o entendimento do esforo requerido pelo projeto.
A estimativa de custos inclui as despesas com recursos e materiais. Estimativas de esforo
englobam o nmero total de horas de trabalho necessrias para concluir o projeto. Estima Gerenciamento de Projetos de TI
tivas de tempo incluem o tempo total necessrio para a finalizao do projeto com sucesso.
48
A figura 3.4 similar ao que foi visto sobre planejamento, mas a parte de estimativas foi
desdobrada para destacar os componentes de esforo, tempo e custos. Veremos a relao
entre esses componentes. Adiante veremos como o cronograma uma alocao do esforo
sobre o tempo, e como o oramento uma alocao do custo sobre o tempo.
Riscos
Necessidade
Escopo
Trabalho (EAP)
Esforo
Tempo
Custos
Cronograma
Figura 3.4
Esforo, tempo e
custos.
Oramento
Os seguintes tpicos sero discutidos a seguir:
11 Causas de falhas em projetos;
11 Importncia de estimativas;
11 Criando uma estimativa de esforo;
11 Estimativas de tempo;
11 Criando uma estimativa de custos;
11 Identificando problemas com estimativas.
Causas de falhas em projetos

11 As estimativas de esforo de um projeto possibilitam o detalhamento desse esforo
em termos de recursos, o que facilita o entendimento do custo do projeto e do tempo

de sua execuo.
11 Nesse ponto, invariavelmente, haver a anlise das atividades relacionadas com o
projeto e dos requisitos previamente estabelecidos.
11 Muitas falhas em projetos de TI so, na verdade, apenas falhas nas estimativas, que
podem acontecer por causa de:
22 Requisitos falhos ou que mudam a todo instante.
22 Falta de familiaridade com as tarefas e atividades.
Muitas falhas em projetos atrasados ou cujos oramentos foram estourados so, na
verdade, apenas falhas nas estimativas. Estimativas ruins acontecem devido ao seguinte:
Requisitos falhos ou que mudam a todo instante ao planejar o esforo, o gerente do
providenciar o seu esclarecimento, caso necessrio. Os requisitos do projeto precisam estar
fortemente acoplados com o objetivo de negcio como um todo.
Falta de familiaridade com as tarefas e atividades o recurso que vai estimar as atividades
precisa conhecer o domnio da aplicao. O gerente do projeto precisa considerar fatores de
experincia e familiaridade tanto nas estimativas quanto na realizao do trabalho.
projeto precisa garantir que os requisitos previamente desenvolvidos fazem sentido e
49
Obviamente, a primeira implicao que os requisitos precisam ser estabelecidos atravs

do processo de escopo. Estimativas a partir de requisitos falhos aumentam o risco de scope
creep ou da entrega de uma aplicao problemtica, que demandar retrabalho.
Um dos objetivos do processo de detalhamento de trabalho descrever as tarefas em
um nvel de familiaridade suficiente para facilitar o processo de estimativa. Orientao de
experts e registros de performance devem ser aplicados, levando em considerao o nvel
adequado de familiaridade.
As estimativas devem ser revisadas, pelo menos, ao iniciar cada uma das fases posteriores
do projeto; s faz sentido o acompanhamento do cronograma e dos custos de um projeto se
houver certo nvel de confiana na estimativa realizada.
Importncia das estimativas

11 As estimativas so importantes porque orientam o cronograma.
11 O gerente de projetos provavelmente ter de revisar as estimativas continuamente.

A prxima tabela define os trs principais elementos de estimativas, e sua importncia no
processo de planejamento.
Descrio
Benefcio
Determinar a quantidade total de trabalho

necessria (horas totais ou FTE).
Garante que recursos apropriados so fornecidos ao

projeto.
Determinar o tempo necessrio para realizar

o trabalho.
Estabelece uma expectativa de permitir que membros do

time calculem o seu tempo.
Calcular o custo para o trabalho definido,

incluindo pessoas, equipamento e facilidades.
Permite medir os benefcios como uma funo de custos.
As estimativas so importantes porque orientam o cronograma. Mesmo assim, o gerente de

projetos provavelmente ter de revisar as estimativas continuamente, com base em acontecimentos e novas informaes obtidas durante as fases subsequentes de planejamento e
execuo.
Criando uma estimativa de esforo

11 Esforo o nmero total de horas (ou dias) necessrio para a concluso de uma
determinada atividade.
11 Por exemplo, se for necessrio que duas pessoas trabalhem 40 horas por semana para
terminar uma atividade em uma semana, ento o esforo necessrio de 80 horas.
11 O esforo normalmente mensurado em termos de jornada de trabalho ou Full-Time
Equivalent (FTE).
50
22 Se 40 horas esto definidas como um nmero regular de horas que um recurso

deve trabalhar em uma semana, ento isso equivalente a um FTE.
22 O total de FTEs ser a soma de todas as horas de trabalho colocadas em todos os
recursos, divididas por 40.
11 A estimativa de esforo orienta o nmero de recursos necessrios (homens/hora)
para executar um projeto.
Tabela 3.5
Trs principais
elementos de
estimativas.
Esforo o nmero total de horas (ou dias) necessrio para concluir uma atividade especfica.
Isto , se necessrio que duas pessoas trabalhem 40 horas por semana para terminar uma
atividade em uma semana, ento o esforo necessrio de 80 horas. O esforo normalmente mensurado em termos de jornada de trabalho ou Full-Time Equivalent (FTE). Se 40
horas esto definidas como um nmero regular de horas que um recurso deve trabalhar
em uma semana, ento isso equivalente a um FTE. O total de FTEs ser a soma de todas as
horas de trabalho colocadas em todos os recursos, divididas por 40. A estimativa de esforo
orienta o nmero necessrio de recursos.
Destaques em estimativas de esforo
Uma estimativa correta utiliza pelo menos uma das seguintes tcnicas:
11 Experincia.
11 Atividades ou entregveis.
11 Pontos de funo.
Uma estimativa correta utiliza pelo menos uma das seguintes tcnicas:
11 Experincia: aceitvel quando tanto o problema de negcio quanto o problema
tcnico fazem parte da gama de conhecimentos do recurso que est sendo estimado;
11 Atividades ou entregveis: estimativas por atividades ou entregveis produzem
uma estimativa geral; requer uma metodologia de desenvolvimento de aplicaes
que inclua as atividades e os entregveis, um banco de dados de mtricas relacionadas e fatores de varincia (como complexidade);
11 Pontos de funo: usa uma estimativa de ponto de funo (tamanho) e registros de
mtricas de produtividade para calcular o esforo; pontos de funo quantificam as
funes realizadas em relao a requisitos de negcio; o mtodo para contar funes
est descrito no grupo internacional de usurios de ponto de funo (IFPUG), dentro
do IFPUG Counting Manual.
Estimando varincia
Para antever a variabilidade nas estimativas de um determinado projeto, necessrio
realizar a avaliao e a reviso do esforo de cada uma das atividades do projeto.

11 A reviso precisa calcular o tempo esperado para execuo de uma atividade e a
possvel variabilidade dessa estimativa.
Um mtodo utilizado para estimar varincia o chamado Project Evaluation and Review
Technique (PERT).
11 Considera estimativas de tempo otimistas, pessimistas e mais provveis para cada
uma das atividades.
Os mtodos mostrados anteriormente, tanto sozinhos ou combinados, so normalmente
provimento de uma estimativa otimista e pessimista para quantificar riscos relacionados ao
tempo do projeto.
A tcnica de avaliao e reviso de projetos (PERT Project Evaluation and Review Technique) descreve um mtodo para usar as estimativas otimista, mais provvel e pessimista de determinada atividade, para o clculo do valor esperado de esforo e da
variabilidade do esforo relacionado a ela.
usados para prover uma estimativa mais provvel de esforo. Tambm podem ser teis no
51
Estimativas de tempo
11 O objetivo de se estimar o esforo das atividades de um projeto definir quanto
tempo ser necessrio para a sua execuo.

11 Para ter essa informao, necessrio calcular a relao entre esforo de projeto e
disponibilidade de recursos.
11 Enquanto a estimativa de esforo em projetos de TI normalmente dada em termos de
homens/hora, as estimativas de tempo so funes de tempo (horas, dias, semanas).
11 Estimar o tempo do projeto o primeiro passo para obter seu cronograma.
Uma estimativa de tempo a quantidade de tempo que ser necessria para concluir o
projeto, estando intimamente relacionada com a estimativa de esforo.
Destaques em estimativas de tempo
11 Estimativas de tempo so uma funo das estimativas de esforo.
11 Um gerente de projetos precisa considerar se as atividades podem ser divididas entre

diferentes pessoas.
11 Duas pessoas trabalhando 40 horas por semana para terminar uma atividade em
uma semana tem como resultado um esforo de 80 horas (o tempo da atividade
continua de 40 horas).
Estimativas de tempo devem, portanto, ser vistas como funo das estimativas de esforo.
Para derivar o tempo de um projeto, ou de suas fases e atividades, necessrio calcular
como o esforo do projeto se distribui em relao disponibilidade dos recursos destinados
ao projeto.
Um gerente de projetos precisa considerar se cada uma das atividades pode ser dividida
entre diferentes pessoas; importante utilizar os lderes tcnicos da organizao para
essa finalidade. Se for necessrio que duas pessoas trabalhem 40 horas por semana para
terminar uma atividade em uma semana, ento o esforo necessrio ser de 80 horas, e o
tempo necessrio de 40 horas.
Criando uma estimativa de custos

11 A estimativa de esforo de um projeto, aliada a questes de disponibilidade de
recursos, possibilita tambm a totalizao dos custos associados a cada uma das
atividades do projeto.
11 Para calcular os custos em um projeto, necessrio analisar os seguintes fatores:
22 Trabalho.
22 Equipamento e material.
22 Facilidades.
11 Alguns desses custos so diretamente contabilizados ao projeto; outros so compartilhados com outros projetos e cobrados como overhead.
Custos em um projeto so formados a partir do seguinte:
11 Trabalho: a quantidade do trabalho associada a cada uma das atividades e, por conseguinte, do projeto como um todo;
11 Equipamento e material: recursos no humanos, que geram custos ao projeto e precisam tambm de planejamento;
11 Facilidades: localidades onde o trabalho do projeto precisa acontecer.
52
Alguns desses custos so diretamente contabilizados ao projeto; outros so compartilhados

com outros projetos e cobrados como overhead. O gerente do projeto precisa documentar a
forma de recuperao de despesas de cada um dos custos do projeto.
Identificando problemas com estimativas

11 Aps o levantamento das estimativas de esforo, tempo e custo do projeto, neces-
srio realizar uma anlise para se certificar de que atendem as necessidades do

projeto e os requisitos de negcio associados.
11 importante que o gerente do projeto busque o feedback de diversas pessoas.
22 Especialmente daquelas que j possuem experincia com projetos semelhantes.
11 O gerente do projeto precisa ter habilidade para identificar os fatores adicionais que
podem ser considerados e a forma como alterariam as estimativas.
Faa os seguintes questionamentos para ajudar na reviso de estimativas:
11 Podemos aplicar dados de apoio na forma de tempo e custo?
11 Pela minha experincia, essas estimativas so razoveis?

11 Existem requisitos de recurso para cada uma dessas atividades?
Como fatores de projeto influenciam as estimativas
A importncia de uma definio de requisitos e da familiaridade com as tarefas j foi vista. A
tabela 3.6 faz um detalhamento mostrando como eles se relacionam com estimativas de
esforo, tempo e custo.
Esforo
Tempo
Custo
Determinado de maneira abrangente em relao a outros projetos.
Se flexvel, pode concordar em estender

o projeto se for para reduzir custos ou
melhorar a qualidade.
Pode ser fixo ou construdo para

atender requisitos.
Quantas horas de recurso so

necessrias para a concluso dessa
atividade?
Se fixo, pode aumentar os custos ou

reduzir a qualidade.
Se o custo for uma prioridade,

restries de qualidade ou tempo
podem ser relaxadas.
Influenciado pelo nvel de conhecimento

dos recursos e sua disponibilidade.
Inclui custos de trabalho e material,

como hardware ou software.
Como os FTEs sero utilizados?
Estimativas so mais corretas nesse

nvel.
Um novato geralmente demora

mais do que um recurso experiente.
Mais experincia pode impactar o

tempo de aprendizagem.
Quando mais experiente, mais caro

o recurso.
Considere outras prioridades, projetos e frias.
Esperar que recursos se tornem disponveis aumenta o tempo.
Quantos recursos desse tipo so

necessrios?
Aumentar disponibilidade de recursos

reduz o tempo.
Oferta e procura determinam que

recursos com disponibilidade limitada sejam geralmente mais caros.
melhor pagar hora extra a um

recurso ou contratar dois?
O custo dos recursos normalmente

reduzido ao se relaxar requisitos de
tempo.
Tabela 3.6
Definio de
requisitos e da
familiaridade com
as tarefas.
Diretamente relacionado a custo;

quando possvel, tente otimizar
custo unitrio.
Influenciado pelo nvel de conhecimento dos recursos, custos e

disponibilidade.
53
Estimativas de esforo, tempo e custo
A Baker Street Books uma subsidiria de uma grande loja de bens esportivos. A livraria
recentemente abriu sua sexta loja na parte norte do estado, e as lojas esto sempre prximas loja matriz. Embora tenha sucesso no seu nicho de mercado de livros relacionados a
esportes e natureza, a Baker Street Books est lentamente se movendo dentro do mercado,
reconhecendo a ameaa constante das grandes lojas de departamento. As operaes da
Baker Street so independentes da sua empresa me, e ela atualmente possui um banco
de dados do Microsoft Access para o gerenciamento de inventrio e controle. Desde que as
duas ltimas lojas foram adicionadas, o tempo de resposta geral continuou a se deteriorar, o
que tem provocado frustrao dos funcionrios e irritao dos clientes.
Um representante da Baker Street Books contratou a sua empresa para desenvolver um
novo sistema de banco de dados relacional, que armazenar os dados no centro de distribuio para prover acesso mais rpido. Os requisitos adicionais so tais que o sistema deve
ser finalizado dentro de 6 meses, a partir da data inicial, permitindo a Baker Street Books
gerenciar seu inventrio de maneira mais eficiente, facilitar seu uso e manuteno, prover
capacidade de expandir sua linha de produtos e permitir a adio de novas lojas no futuro.
Voc foi designado gerente de projetos e, nesse momento, no tem certeza se h necessidade de converso de dados. Seu contato na loja principal lhe forneceu informaes adicionais sobre o novo sistema: cada loja ter permisso de ver seu prprio inventrio e localizar
livros. Um treinamento ser necessrio para os usurios do sistema, e todas as lojas estaro
ligadas em rede ao centro de distribuio de maneira que, caso uma loja no possua um
dado livro, poder entrar em contato com o centro de distribuio e requisitar que este seja
enviado diretamente para o consumidor.
1. Liste as possveis aes que voc pode tomar para determinar a quantidade de esforo
(horas de trabalho) necessrio para o projeto da Baker Street Books.
2. Quando voc souber a quantidade de horas que o projeto vai precisar para cada uma das
atividades listadas, que informao adicional ser necessria para a realizao de uma
estimativa de tempo?
3. Formule exemplos para cada uma das categorias de custo:
Categoria de custo
54
Exemplos
Custos de trabalho
(homens/hora)
Custos com
equipamento e
material
Custos com
facilidades
Custos indiretos
(overhead)
Tabela 3.7
Custos.
4
Plano de gerenciamento do projeto
de custos bottom up. Identificar critrios para selecionar adequadamente membros
do time de projeto. Identificar critrios para seleo de fornecedores. Criar um plano
para gerenciar os recursos de um projeto. Escolher entre mtodos de comunicao
formais ou informais. Identificar as mtricas de performance de qualidade de um
projeto e como estas sero monitoradas.
conceitos
Cronograma. Custos. Recursos Humanos. Aquisies. Comunicaes. Qualidade.
Criando um cronograma de projeto

11 A Gerncia do Tempo do Projeto inclui os processos e ferramentas necessrias para
assegurar que o projeto ser implementado no prazo previsto

11 Criar o cronograma significa determinar as datas de incio e fim para as atividades
do projeto
22 Se as datas de incio e fim no forem realsticas, improvvel que o projeto
termine como planejado
11 Uma das ferramentas utilizadas pelo cronograma do projeto a criao de diagramas
que reflitam a lgica do projeto
11 Esses diagramas tambm podem ser utilizados para visualizar o caminho crtico
do projeto
De maneira geral, o cronograma do projeto a ferramenta utilizada para comunicar a linha
de tempo do projeto. Em uma viso mais granular, ele tambm identifica as datas de incio e
fim de cada tarefa do projeto, os marcos para concluir as atividades principais, as dependncias entre as atividades, os requisitos de recursos e atribuies. Vrios mtodos de acompanhamento do cronograma de um projeto podem incluir calendrios, chart the Gantt e um
chart PERT. O caminho crtico identificado como uma srie de atividades que precisam ser
concludas pelo projeto no tempo planejado.
Captulo 4 - Plano de gerenciamento do projeto
objetivos
Identificar os componentes de um cronograma de projeto. Criar uma estimativa
55
Importncia de um cronograma
O cronograma do projeto separa atividades atravs da durao do projeto para se certi-
ficar que o projeto concludo a tempo. Um cronograma de projeto criado para:

11 Coordenar tarefas com outras atividades organizacionais que estejam ocorrendo fora
do projeto
11 Coordenar tarefas e dependncias dentro do prprio projeto
11 Alocar recursos atravs do tempo
11 Identificar conflitos de cronograma e super alocao de recursos de projeto
22 Identificar problemas em potencial antes que eles aconteam
O cronograma do projeto separa atividades atravs da durao do projeto para se certificar
de que o projeto concludo a tempo, alm de evitar estouros de custo e qualidade.
Um cronograma de projeto criado para:
Coordenar tarefas com outras atividades organizacionais que estejam ocorrendo fora
do projeto.
Projetos existem dentro de um contexto organizacional maior, e importante garantir
que no h conflitos de cronograma entre o projeto e outros projetos ou outras operaes
funcionais de negcio. Alm disso, o gerente de projetos precisa considerar conflitos de
cronograma com feriados e eventos da empresa.
Coordenar tarefas e dependncias dentro do prprio projeto.
A EAP no define a ordem das atividades. O cronograma determina a ordem das atividades
da EAP e garante que as primeiras coisas sejam feitas primeiro.
Alocar recursos atravs do tempo.
O cronograma define o que feito quando, mas para determinar se o cronograma vivel,
necessrio determinar quem far o qu, e quando.
Identificar conflitos de cronograma e super alocao de recursos de projeto.
Uma parte das atividades necessrias para determinar a viabilidade de um cronograma
passa pela garantia que recursos chave (pessoas, equipamento e facilidades) estejam disponveis quando necessrio. O planejamento do tempo para algumas atividades crtico para
a concluso do projeto na hora correta, ento o gerente de projetos precisa garantir que ele
vai possuir os recursos que suportem o cronograma.
Identifique problemas em potencial antes que eles aconteam.
O gerente de projetos pode acabar notando o surgimento de problemas que no havia per-
56
cebido sem estabelecer suas expectativas atravs do cronograma.
l
Em projetos complexos,
o cronograma no deve
ser encarado como um
caminho fixo, mas na
verdade como uma
forma de organizar,
comunicar e comparar
expectativas com a
realidade.
Componentes de um cronograma
11 O cronograma desenvolvido usando estimativas de tempo para cada atividade
da EAP
11 Um cronograma de projeto deve incluir o seguinte:
22 Datas planejadas para o incio e esperadas para o fim de todas as atividades de
projeto
22 Principais marcos e/ou eventos chave necessrios para implantar o projeto
22 Dependncias e a sequncia que as atividades precisam seguir
11 H trs principais formas de apresentar o cronograma visualmente, e cada uma
possui vantagens e desvantagens. Podemos citar as trs formas mais conhecidas:
11 Calendrio
11 Grfico de Gantt (em barras)
11 Diagrama PERT/CPM (em setas)
O cronograma desenvolvido usando estimativas de tempo para cada atividade da EAP.
Um cronograma de projeto deve incluir o seguinte:
11 Datas planejadas para o incio e esperadas para o fim de todas as atividades de projeto;
11 Principais marcos e/ou eventos chave necessrios para implantar o projeto (incluindo
relatrios relacionados como relatrio de status, relatrios de oramento e de alocao
de recursos).
Dependncias e a sequncia que as atividades precisam seguir.
H trs principais formas de apresentar o cronograma visualmente, e cada uma possui vantagens e desvantagens. Podemos citar as trs formas mais conhecidas:
11 Calendrio;
11 Grfico de Gantt (em barras);
11 Diagramas de Precedncia PERT/CPM (em setas).
Existem vrios programas de gerenciamento de projetos disponveis, como o Microsoft
Project, que permitiro criar essas trs formas de acompanhamento visual dos compo-
Diagramas de Precedncia
11 Os diagramas de precedncia constrem o cronograma no formato de diagrama
de rede e utilizam quadrados ou retngulos (ns) para representar as atividades,
conectando-as por setas que representam as dependncias entre as atividades.
11 As relaes de precedncia entre as atividades podem ser de quatro tipos:
22 Trmino-para-Incio (finish-to-start)
22 Trmino-para-Trmino (finish-to-finish)
22 Incio-para-Incio (start-to-start)
22 Incio-para-Trmino (start-to-finish)
nentes do projeto.
57
Esse um mtodo de construo de diagrama de rede que utiliza quadrados ou retngulos

(ns) para representar as atividades e as conecta por setas que representam as dependncias:
A
Figura 4.1
Desenho de
diagrama de rede
lgica usando
o mtodo do
Diagrama de
Precedncia.
C
Trmino
Incio
D
A figura 4.1 apresenta um diagrama simples de rede lgica desenhado utilizando o PDM.
Essa tcnica tambm chamada deatividade em n(AON: Activity-on-node) e o mtodo
utilizado pela maioria dos pacotes de programas para gerncia de projeto. O PDM pode ser
feito manualmente ou no computador. Isso inclui quatro tipos de relacionamento de dependncia ou precedncia:
11 Trmino-para-Incio (finish-to-start) o incio de uma atividade sucessora depende do
trmino da atividade predecessora;
11 Trmino-para-Trmino (finish-to-finish) o trmino de uma atividade sucessora depende
do trmino da atividade predecessora;
11 Incio-para-Incio (start-to-start) o incio de uma atividade sucessora depende do incio
da atividade predecessora;
11 Incio-para-Trmino (start-to-finish) o trmino de uma atividade sucessora dependente do incio da atividade predecessora.
O PDM trmino/incio (finish-to-start) o tipo de relacionamento lgico mais comumente usado.
Os relacionamentos incio/trmino (start-to-finish) so raramente usados e assim mesmo
apenas por engenheiros profissionais de programao. Usar incio/incio (start-to-start),
trmino/trmino (finish-to-finish) ou incio/trmino (start-to-finish) em softwares de gerncia
de projetos pode produzir resultados inesperados, caso os tipos de relacionamento no
tenham sido implementados consistentemente.
Caminho crtico
11 O caminho crtico pode ser definido, simploriamente, como a sequncia de atividades
que determinam a data de concluso do projeto

11 Se uma atividade no caminho crtico for completada um dia mais tarde, ento a concluso do projeto tambm ser atrasada em um dia
11 Ou seja, a importncia do caminho crtico vem de sua definio: o atraso de suas
atividades ameaa a programao do projeto
Caminho crtico um termo criado para designar um conjunto de tarefas vinculadas a
uma ou mais tarefas que no tm margem de atraso e determinam a data de concluso do
projeto. O caminho crtico a sequncia de atividades que devem ser concludas nas datas
58
programadas para que o projeto possa ser concludo dentro do prazo final. Se o prazo final
for excedido, porque no mnimo uma das atividades do caminho crtico no foi concluda
na data programada.
importante entender a sequncia do caminho crtico para saber onde voc tem e onde
voc no tem flexibilidade. Por exemplo, voc poder ter uma srie de atividades que foram
concludas com atraso, no entanto, o projeto como um todo ainda ser concludo dentro do
prazo, porque essas atividades no se encontravam no caminho crtico.
Por outro lado, se o seu projeto est atrasado, e a alocao de recursos adicionais em
atividades que no esto no caminho crtico no far com que o projeto termine mais cedo.
Se uma atividade no caminho crtico for completada um dia mais tarde, ento a concluso
do projeto tambm ser atrasada em um dia (a no ser que as atividades posteriores no
caminho crtico sejam completadas mais rapidamente do que originalmente planejado).
Por que o caminho crtico importante?
A importncia do caminho crtico clara desde a sua definio. Se uma atividade no
caminho crtico atrasa, ela imediatamente ameaa atrasar a concluso do projeto. A principal prioridade do gerente de projeto identificar rapidamente as atividades do caminho
crtico, monitor-las e criar planos de contingncia e preveno para evitar atrasos.
Quando o caminho crtico no importante?
Os fatores que fazem o caminho crtico se tornar menos importante so riscos, custos e
qualidade. A definio tradicional de caminho crtico leva em considerao apenas a durao
esperada da atividade. Entretanto, atividades associadas a riscos muito severos, que
estejam no caminho crtico ou prximas a ele, tambm so de gerenciamento crtico.
A prxima sesso rev mtodos para calcular o caminho crtico, e sesses posteriores revisaro mtodos para monitorar custos (varincia de oramento) e qualidade.
Determinando as folgas
Determinando as folgas de atividade
11 Folga (slack ou float) = trmino mais tarde (LF) trmino mais cedo (EF) ou
11 Folga = incio mais tarde (LS) incio mais cedo (ES)
O caminho crtico ter sempre folga zero
Qualquer uma das dependncias pode requerer especificaes de folgas e flutuaes com a
finalidade de definir precisamente o relacionamento de precedncia entre as atividades do
projeto. Um exemplo de folga: podemos desejar um atraso de duas semanas no cronograma
entre a fabricao de uma pea de equipamento e a instalao ou uso. Um exemplo de uma
sucessora comea dez dias antes da predecessora estar completa.
flutuao, em uma dependncia fim-para-incio com uma flutuao de dez dias: a atividade
59
Determinando as folgas IDA

Para se concluir o caminho crtico, necessrio determinar as folgas para todas as atividades do projeto. O primeiro passo para isso calcular ES e EF:
ES
EF
ES
EF
ES
EF
13
13
17
D=5
D=8
D=4
LS
Incio
LF
LS
LF
LS
LF
Primeira atividade!
ES
EF
17
21
Repete o valor
de incio ...
LS
ES
EF
ES
EF
ES
EF
11
LS
D=4
D=2
D=5
LF
LS
ES
EF
LF
LS
D=5
ES Suc = Maior EF Pred

EF = ES+D
LF
Para calcular ES e EF, repita o valor de incio do projeto (dia 0) como ES de todas as atividades
que divergem diretamente do incio do projeto. A partir da, calcule o EF dessas atividades
de acordo com a frmula: eF = ES + D (sendo D = durao da atividade). Para as atividades
sucessoras, use a frmula: eS(sucessora) = Maior EF(predecessoras).
60
LF
LF
F
LS
Fim
21
D=4
Convergncia
Determinando as folgas VOLTA

Para se concluir o caminho crtico, necessrio determinar as folgas para todas as ativi-
dades do projeto. O segundo passo para isso calcular LS e LF:
ES
EF
ES
EF
ES
EF
13
13
17
D=8
D=5
A
LS
LF
LS
13
13
LF
LS
17
LF
Incio
ES
EF
17
21
D=4
17
LS
ES
EF
ES
EF
ES
EF
11
D=4
6
LS
D=2
10
10
LF
LS
ES
EF
12
LF
LS
17
LS
21
21
LF
ltima atividade!
da linha de cima...
LF
D=5
7
21
Repete os valores
D=5
12
Fim
LF Pred = Menor LS Suc

LS = LF D
12
LF
Para calcular LS e LF, repita o valor de data de fim do projeto (no exemplo, dia 21) como LF
de todas as atividades que convergem diretamente ao incio do projeto. A partir da, calcule
o LS dessas atividades de acordo com a frmula: lS = LF: D (sendo D = durao da atividade).
Para as atividades predecessoras, use a frmula: lF(sucessora) = Menor LS(predecessoras).
Exemplo de sequenciamento para caminho crtico

11 Para calcular LF e LS, primeiro calcule o caminho mais longo da primeira at
a ltima atividade
11 Esse ser o tempo LF para todas as atividades no seu diagrama de setas
D=4
61
Os passos para se determinar o caminho crtico esto na tabela 4.13:

Passo
Descrio
1. Liste os predecessores imediatos da

atividade da WBS.
Atividade
Cdigo
Durao
Predecedor
Selecionar Software
--
Selecionar Hardware
--
Instalar Hardware
Instalar Software
1,3
Desenvolver Scripts
1,3
Testar Mdulos
12
Testar Sistema
Aceitar Sistema
6,7
Cdigo
Durao
ES
EF
LF
LS
Folga
Earliest Start (ES): incio mais cedo
maior EF entre todos os predecessores.
10
12
12
10
22
10
10
12
20
14
14
22
23
22
22
2. Desenhe um diagrama de setas mostrando

as atividades da WBS, os tempos e
a sequncia.
3. Defina os tempos de incio, fim e folgas

das atividades:
Earliest Finish (EF): incio mais tarde

ES mais a durao.
Latest Finish (LF): fim mais tarde
mnimo LS de sucessores imediatos.
Latest Start (LS): incio mais tarde
LF menos a durao.
Slack Time (ST): folga
LS menos ES ou LF menos EF.
4. Sequncia do caminho crtico com folga zero.
2g3g4g6g8
Os tempos LS e o LF para cada atividade so determinados ao se trabalhar de trs para frente, do fim do
projeto ao incio.
62
Tabela 4.1
Passos para
determinar o
caminho crtico.Para
calcular LF e LS,
primeiro calcule o
caminho mais longo
da primeira at a
ltima atividade.
Esse ser o tempo
LF para todas as
atividades no seu
diagrama de setas.
Variabilidade do Caminho Crtico

11 A partir do momento em que atrasos maiores aconteam em caminhos no crticos,
possvel que esses venham tambm a se tornar crticos para o projeto

11 As atividades ao longo desses quase caminhos crticos devem ser monitoradas de
maneira muito prxima
11 imprescindvel realizar uma anlise de riscos para o caminho crtico e seus
possveis variantes
Um mtodo para quantificar riscos no caminho crtico atravs de estimativas PERT, de
clculo um tempo esperado e um desvio padro no tempo de cada atividade.
A anlise do caminho crtico atravs de estimativas PERT acontece da mesma forma como
descrito anteriormente, mas usando o tempo esperado (Te). Uma simples extenso tambm
calcularia o desvio padro dos caminhos e procuraria por caminhos que estivessem localizados dentro de dois desvios padro do caminho crtico.
As atividades ao longo desses quase caminhos crticos, que apresentam a maior contribuio para o caminho crtico (pois so aquelas que tm o maior nvel de incerteza), devem
ser monitoradas de maneira muito prxima.
Criando um oramento de projeto

11 A gerncia do custo do projeto inclui os processos necessrios para assegurar que o
projeto ser concludo dentro do oramento aprovado

11 A gerncia do custo do projeto consiste, fundamentalmente, nos custos dos recursos
necessrios para a implementao das atividades do projeto
11 Entretanto, a gerncia do custo do projeto deve, tambm, considerar os efeitos das
decises do projeto no custo de utilizao do produto do projeto
O planejamento dos custos se d atravs de um oramento bottom-up. A oramentao
leva em considerao a hora em que os gastos ocorrero, o padro de gastos do projeto e a
frequncia dos gastos. A varincia de custos usada atravs do ciclo de vida do projeto para
calcular o oramento inicialmente alocado e o que de fato foi gasto. Um fundo de contingncia deve ser criado para uso em caso de restries de fundos. Veremos adiante como se
Criando um oramento bottom-up

11 Um oramento bottom-up comea com estimativas de custos detalhadas.
11 Em sua forma mais simples, um oramento bottom-up a soma de custos, incluindo

subtotais para vrias fases de projeto, subprojetos e marcos.
11 O oramento pode ajudar a demonstrar se o gerente de projetos pode se comprometer com o oramento top-down desenvolvido durante a fase de escopo do projeto.
Um oramento bottom-up comea com estimativas de custos detalhadas. Em sua forma
mais simples, um oramento bottom-up apenas a soma de custos, incluindo subtotais
para vrias fases de projeto, subprojetos e marcos. O oramento pode ajudar a demonstrar
que o gerente de projetos pode, de fato, se comprometer com o oramento top-down que
foi desenvolvido durante a fase de escopo do projeto. Um oramento til tem de ir alm dos
custos esperados e prover uma estimativa da alocao ao longo do tempo para se ter uma
cria um oramento bottom-up.
ideia da permissividade dos riscos.

63
Alocao
11 No nvel organizacional, projetos muito caros podem afetar os fluxos de caixa da
empresa e a performance financeira

11 Os principais gastos, como capital de equipamento, devem ser planejados com
muito cuidado
11 Tanto por causa do cronograma do projeto, quanto por causa do impacto financeiro
para a empresa
11 Comparar gastos planejados com gastos incorridos, durante todo o projeto, pode
sinalizar um potencial descontrole de custos
Oramentos de projeto eficientes precisam considerar quando os gastos ocorrero.
O tempo necessrio por duas razes:
11 No nvel organizacional, projetos muito caros podem afetar os fluxos de caixa da empresa
e a performance financeira. Dessa forma, os principais gastos, como capital de equipamento, devem ser planejados com muito cuidado, tanto por causa do cronograma do
projeto, quanto por causa do impacto financeiro para a empresa;
11 No nvel de projeto, o controle do momento dos gastos permite o monitoramento para
saber se as expectativas do projeto no estejam sendo satisfeitas. Uma comparao dos
gastos planejados com os gastos efetuados, ao longo de todo o projeto, pode sinalizar um
potencial descontrole de custos. Esse ponto ser visto mais frente, quando os mtodos
para o monitoramento de custos sero revisados.
Risco e varincia
A diferena entre o oramento inicial do projeto e o gasto incorrido chamado de
varincia. Alguns fatores podem influenciar a varincia, tais como:

11 Efetividade das estimativas
11 Inflao
11 Disponibilidade de recursos
11 Uso de horas-extras
11 Flutuaes naturais de preo
Varincia de custos pode ser detfinida como a diferena entre o oramento inicial do
projeto e o gasto verdadeiramente incorrido. Existem diversos fatores que podem influenciar a variablidade de custos, podendo ser de diversas naturezas, desde problemas com
planejamento, tais como efetividade das estimativas, disponibilidade de recursos e uso de
horas-extras, at problemas que fogem ao controle do projeto, como inflao e flutuaes
naturais de preo.
64
Contingncia de riscos e custos

O oramento deve incluir uma contingncia de gerenciamento que deve ser controlada pelo
gerente de projeto. Muitas fontes recomendam apenas aumentar o oramento, para se
proteger de fatores de risco. Entretanto, no existe uma recomendao precisa acerca da
quantidade de fundos que precisa ser alocada e a forma como esse fundo adicional gerenciado pode se tornar um fator de insucesso para o projeto.
O projeto deve ser gerenciado para que o valor esperado para o esforo, os custos e a
durao de cada atividade acontea de acordo com planejado. Isso significa que o tempo e o
dinheiro devem ser alocados no valor esperado. O fundo de contingncias deve ser visto como
uma ferramenta separada dos fundos normais, e de onde os fundos so tirados apenas no
caso do gerente do projeto, explicitamente, decidir que uma correo ou adaptao apropriada precisa dos fundos.
Para decidir o nvel do fundo de contingncia, vrias regras so sugeridas, como a adio de
10 a 100% do custo, para permitir uma margem satisfatria de riscos.
Um mtodo mais rigoroso e cientfico para justificar a contingncia baseado nos clculos
estatsticos PERT que foram realizados anteriormente, durante as fases de estimativa e
na concluso do caminho crtico. Por exemplo, os recursos necessrios para completar a
sequncia mais longa de caminhos, aps de a sequncia ter sido estendida para dois desvios
padres do esforo, devem ser includos na contingncia.
A contingncia tambm precisa considerar os detalhes do gerenciamento de riscos. Quanto
maior o nvel de controle de um determinado risco, maior contingncia ser necessria. Por
exemplo, se possvel, o oramento de contingncia deve permitir a aquisio de equipamentos para substituio ou reserva.
Criando um plano de gerenciamento de fornecedores

11 A Gerncia de Aquisies do Projeto inclui os processos necessrios obteno de
bens e servios para realizar o escopo do projeto, externos organizao executora

11 Para simplificao, os bens e servios, seja um ou vrios, sero geralmente referidos
como umproduto
11 A Gerncia de Aquisies do Projeto discutida do ponto de vista do comprador na
relao comprador-fornecedor
11 Essa sesso assume que o fornecedor externo organizao executora
22 A maioria da discusso, entretanto, igualmente aplicvel aos acordos formais
negociados com outras unidades da prpria organizao
Em todo projeto de larga escala, uma reviso de sua EAP vai revelar atividades que podem
ser realizadas internamente e outras que sero contratadas junto a fornecedores externos.
A seleo de fornecedores depende de vrios fatores, como custo, suporte e performance.
Vrios fornecedores devem ser entrevistados por seus servios, e o candidato final selecionado baseado na sua entrevista, referncias de trabalhos realizados no passado e sistemas de
suporte a qualidade. Um contrato bem escrito com o fornecedor escolhido uma parte necesgveis, datas de entrega, requisitos de performance e condies de aceitao dos servios.
11 Atividades e entregveis para contratao;
11 Critrio de seleo de fornecedores;
11 Critrios de performance e contratos com fornecedores.
Atividades e entregveis para contratao

O gerente do projeto precisa revisar cada elemento da EAP e determinar as atividades
que devem ser contratadas a fornecedores. Considere o seguinte:
11 A atividade pode ser realizada internamente?
11 Se a tarefa ou o entregvel pode ser realizado internamente, os riscos aumentam ou
sria do plano de gerenciamento de fornecedores e deve conter descries de todos os entre-
diminuem se contratados externamente?

65
11 Qual o impacto em outros projetos se recursos internos forem utilizados para
essa atividade?
11 Se a atividade for realizada por terceiro, a organizao estaria perdendo a oportunidade de adquirir uma competncia crtica?
O gerente do projeto responsvel pela reviso de cada elemento da EAP e por determinar
as atividades e entregveis da EAP que precisam ser contratados junto a fornecedores. Para
responder esse questionamento, necessrio realizar uma anlise detalhada das atividades
e das organizaes envolvidas no projeto, de maneira a responder questes como:
11 A atividade pode ser realizada internamente?
11 Se a tarefa ou o entregvel pode ser realizado internamente, o risco aumenta ou diminui
se fosse contratado externamente?
11 Qual o impacto em outros projetos se recursos internos forem utilizados para essa atividade?
11 Qual o custo esperado de se realizar a atividade internamente versus externamente?
Certifique-se de que a comparao dos custos inclui custos de overhead para o recurso
interno e custos adicionais com gerenciamento para a contratao externa.
11 Se a atividade ou entregvel for realizada por um fornecedor, a organizao estar perdendo uma oportunidade de adquirir uma competncia crtica?
Critrios de seleo de fornecedores

11 Critrios de seleo escritos devem ser desenvolvidos para a avaliao de potenciais
fornecedores
11 necessrio considerar:
22 Critrios quantitativos: custos iniciais, mensais, com gerenciamento e administrao
22 Critrios qualitativos: compatibilidade com a performance existente, performance,
habilidade de gerenciar fornecedores
Critrios de seleo escritos devem ser desenvolvidos para a avaliao de potenciais
fornecedores. O seguinte deve ser considerado:
11 Critrios quantitativos tais quais:
22 Custos iniciais
22 Custos com manunteno mensais
22 Custos com gerenciamento e administrao
11 Critrios qualitativos tais quais:
22 Compatibilidade com a estrutura de suporte existente
22 Performance
66
22 Habilidade organizacional de gerenciar fornecedores
Seleo de fornecedores
Mtodos para avaliao so descritos na tabela 4.2:
Mtodo
Descrio
Questionrios
Fornea questes escritas para os fornecedores sobre seus

processos e suas
capacidades.
Auditorias
Processos de trabalho, exemplo de sistemas e produtos ou

projetos relacionados, para avaliar a capacidade dos fornecedores; auditorias podem tambm ser usadas para confirmar as
respostas dos questionrios.
Entrevistas
Avalie se funcionrios chave sabem o que seus sistemas e processos

dizem que deveriam estar fazendo e como eles planejam satisfazer os
seus requisitos.
Reviso de trabalhos
passados
Examine projetos passados tanto separadamente quanto como

parte de uma auditoria; determine a qualidade do trabalho e
como foi realizado.
Reviso dos sistemas de qualidade

Reviso completa de como o fornecedor atinge requisitos de qualidade, e como ele se
certifica que isso
feito satisfatoriamente.
Contratos de fornecedores e critrios de performance

Aps contratar um fornecedor, os critrios de performance devem ser claramente
documentados na declarao de trabalho:

11 Descrio clara dos requisitos da atividade ou do entregvel
11 Datas de entrega
11 Requisitos de performance
11 Critrios de aceitao
Os critrios para contratar fornecedores devem ser claramente definidos na declarao de
trabalho, que inclui os seguintes pontos:
11 Descrio clara dos requisitos da atividade ou do entregvel;
11 Datas de entrega;
11 Requisitos de performance;
11 Critrios de aceitao.
Esses critrios se tornam crticos para se definir o nvel de resposta do fornecedor e, assim,
a justificativa para o reembolso dos servios. O gerente de projetos deve se certificar que o
teste final e a aceitao dos entregveis so ambos gerenciados adequadamente.
Tabela 4.2
Mtodos para
avaliao.
67
Tipos de contrato
11 Para que um contrato seja executado dentro das expectativas das partes envolvidas,
necessrio o estabelecimento de clusulas e condies

11 Escolher o tipo de contrato a ser utilizado em um fornecimento depende de inmeros
fatores
11 Podemos citar alguns desses tipos a seguir:
22 Contratos de compra e venda
22 Contratos de locao
22 Emprstimo: comodato e mtuo
22 Prestao de servios
22 Empreitada
22 Licitaes
da natureza de todos os contratos serem bilaterais (duas partes, no mnimo) e sinalagmtico (aceitao formal ou tcita das partes). O Cdigo Civil Brasileiro (Lei no. 10.406/2002)
dispe sobre a existncia de formas diferenciadas de contratao e classifica os contratos
em espcies, estabelecendo para cada uma delas caractersticas e funes. Destacamos
algumas destas:
11 Contratos de compra e venda: nesse contrato, uma das partes se obriga a transferir o
domnio (propriedade) de certa coisa, e a que recebe dever pagar o preo correspondente.
11 Contratos de locao: uma das partes se obriga a ceder outra, por tempo determinado
ou no, uso e gozo da coisa no consumvel, mediante certa contribuio. No ocorre a
transferncia de propriedade.
11 Emprstimo (comodato e mtuo): comodato o emprstimo de coisa no consumvel
que no pode ser substituda (cadeiras, equipamentos, imveis). As despesas para manuteno da coisa so de responsabilidade do comodatrio. Mtuo o emprstimo de coisa
consumvel (por exemplo, um saco de cimento). Sua caracterstica a substituio do
produto, por outro de mesmo gnero, qualidade e quantidade.
11 Prestao de servios: toda espcie de trabalho lcito que pode ser contratado,
mediante retribuio, a uma pessoa fsica, excetuados os que no estiverem sujeitos a
leis trabalhistas ou lei especial.
11 Empreitada: nesse tipo de contrato, os servios so realizados para implantar determinada obra, pessoalmente ou por meio de terceiros, mediante determinada remunerao,
de acordo com orientaes do cliente, sem vnculo empregatcio de qualquer natureza.
Nessa espcie de contrato o empreiteiro de uma obra pode contribuir para ela s com o
seu trabalho ou tambm com materiais.
68
11 Licitao: procedimento administrativo formal em que a Administrao Pblica convoca,

mediante condies estabelecidas em ato prprio (edital ou convite), empresas interessadas na apresentao de propostas para o oferecimento de bens e servios. A Lei n
8.666 de 1993, ao regulamentar o artigo 37, inciso XXI, da Constituio Federal, estabeleceu normas gerais sobre licitaes e contratos administrativos pertinentes a obras,
servios, inclusive de publicidade, compras, alienaes e locaes no mbito dos Poderes
da Unio, dos Estados, do Distrito Federal e dos Municpios.
Tipos de licitao:
11 Concorrncia
11 Tomada de preos
11 Convite
11 Prego
Concorrncia
Modalidade da qual podem participar quaisquer interessados que na fase de habilitao
preliminar comprovem possuir requisitos mnimos de qualificao exigidos no edital para
execuo do objeto da licitao. Tomada de preos
Modalidade realizada entre interessados devidamente cadastrados ou que atenderem a
todas as condies exigidas para cadastramento at o terceiro dia anterior data do recebimento das propostas, observada a necessria qualificao.
Convite
Modalidade realizada entre interessados do ramo de que trata o objeto da licitao, escolhidos e convidados em nmero mnimo de trs pela Administrao. O convite a modalidade de licitao mais simples. A Administrao escolhe quem quer convidar, entre os
possveis interessados, cadastrados ou no. A divulgao deve ser feita mediante afixao
de cpia do convite em quadro de avisos do rgo ou entidade, localizado em lugar de
ampla divulgao.
No convite possvel a participao de interessados que no tenham sido formalmente
convidados, mas que sejam do ramo do objeto licitado, desde que cadastrados no rgo ou
entidade licitadora ou no Sistema de Cadastramento Unificado de Fornecedores SICAF.
Esses interessados devem solicitar o convite com antecedncia de at 24 horas da apresentao das propostas.
Para alcanar o maior nmero possvel de interessados no objeto licitado e evitar a repetio do procedimento, muitos rgos ou entidades vm utilizando a publicao do convite
na imprensa oficial e em jornal de grande circulao, alm da distribuio direta aos fornecedores do ramo.
Prego
a modalidade de licitao em que a disputa pelo fornecimento de bens e servios comuns
por lances verbais, independentemente do valor estimado da contratao.
Ao contrrio do que ocorre em outras modalidades, no prego a escolha da proposta feita
antes da anlise da documentao, razo maior de sua celeridade.
O prego modalidade alternativa ao convite, tomada de preos e concorrncia para contratao de bens e servios comuns. No obrigatria, mas deve ser prioritria e aplicvel a
qualquer valor estimado de contratao.
feita em sesso pblica. Os licitantes apresentam suas propostas de preo por escrito e
69
Definindo contrataes junto a fornecedores
O governo do estado do Esprito Santo decidiu modernizar os centros de atendimento de vinte
prefeituras do estado, atravs do estabelecimento de terminais de autoatendimento para a
populao na documentao de servios locais de pessoa fsica (tais como notas azuis, gerao
de boletos de IPTU, entre outros servios). O projeto, que j vem sendo realizado h mais de
um ano, j implantou terminais de uso e reformulou as fachadas das prefeituras envolvidas.
No entanto, por causa de mudanas de ordem poltica, recentemente uma nova administrao
assumiu a responsabilidade pelo projeto e voc foi designado como seu gerente.
Aps uma avaliao inicial do produto, voc e sua equipe perceberam que a administrao
anterior no focou tanto na funcionalidade dos sistemas, mas do apelo visual de seus centros
de atendimento nas prefeituras. Consideraram mais importante que os centros possussem
monitores LED, impressoras a laser e leitores de impresses digital, mas no focou no
desenvolvimento da soluo em si, negligenciando aspectos como dimensionamento nas
necessidades de software e armazenamento. A populao aprovou a forma como os centros
estavam, mas muitas vezes tiveram problemas ao descobrir que no conseguiriam imprimir as
notas fiscais, nem gerar os boletos necessrios, porque o cadastro das empresas no estava
atualizado ou as especificidades de cada contrato no eram contempladas pelo sistema.
Para complementar o projeto, a prefeitura municipal identificou um oramento preliminar
de R$ 5 milhes para desenvolver um novo sistema, que deve contemplar um sistema de
gesto empresarial para possibilitar o cadastro por meio de uma rede de computadores
entre todos os centros de atendimento. Sero incorporados hardware e software de ltima
gerao, disponibilizando administrao de cadastro e atualizao de contratos, incluindo
a automao do processo de emisso de servios em tempo real, bem como cadastro de
pessoa fsica.
Aps a primeira semana no projeto, sua equipe determinou que o software no pode ser
escrito para o hardware legado. Por causa disso, necessria a compra de novos terminais
e novos scanners de cdigo de barra para cada uma das vinte prefeituras contempladas
no projeto, alm de hardware novo tambm para os centros de processamento de dados
governamentais. Somente a pesquisa de adequao por trs desse projeto vai requerer
mais tempo da sua equipe do que ele tem atualmente disponvel, e o secretrio de finanas
do estado recomendou um fornecedor que havia sido utilizado em outro projeto, que ele
julga ser confivel.
O treinamento ser um aspecto crtico desse projeto, pois importante que os funcionrios
da prefeitura sejam capazes de orientar a populao na utilizao do novo sistema, antes da
migrao. Atualmente, a organizao contratada para esse projeto no capaz de cumprir o
cronograma para disponibilizar um treinamento, estimado aps o replanejamento.
70
1. Identifique as atividades ou entregveis que podem ser contratados dos fornecedores, e

determine quais recomendaria para contratao por fornecedores.
2. Descreva em detalhes um mtodo para comunicar critrios de performance para o fornecedor.
Criando um plano de gerenciamento de recursos

Um plano de gerenciamento de recursos:
11 Lista os recursos em um projeto

11 Estipula o tempo de desenvolvimento das vrias tarefas, utilizando equipamentos
e facilidades
Um plano de gerenciamento de recursos deve incluir o seguinte:
11 Cada recurso humano por funo ou habilidade, com as horas que trabalharo no
projeto e o perodo (dia, semana, ou ms)
11 Que tipo de equipamento ser necessrio, por quanto tempo e em que data
11 Facilidades demandadas por pessoas ou pelo equipamento e as datas para o seu
atendimento
Um plano de gerenciamento de recursos acompanha todos os recursos em um projeto, por
quanto tempo os recursos trabalharo em diversas tarefas, utilizando equipamentos e facilidades. Essa sesso apresentar a criao de um plano para gerenciar recursos de projeto.
O plano de gerenciamento de recursos
O grfico de Gantt e as estimativas desenvolvidas anteriormente representam a base de
um plano de gerenciamento de recursos. Esse plano uma tabela, ou planilha, que
mostra o seguinte:
11 Cada recurso humano por funo ou habilidade, e as horas que vo se dedicar ao projeto,
em que perodo (dia, semana ou ms);
11 Que tipo de equipamento ser necessrio, por quanto tempo e a data;
11 Facilidades necessrias demandadas pelas pessoas ou pelo equipamento, e as datas
previstas para a sua realizao.
Para criar um plano de gerenciamento de recursos, liste:
1. Os recursos para cada atividade no grfico de Gantt
2. O perodo de tempo em que sero necessrios
3. A sua disposio de trabalho durante cada atividade
11 Para todas as atividades ser possvel mostrar o tempo total de alocao de cada recurso
Para criar um plano de gerenciamento de recursos, necessrio realizar os seguintes passos:

1. Liste os recursos para cada atividade no grfico de Gantt;
2. Alm das horas em que eles sero necessrios e a sua disposio de horas durante a
durao da atividade;
3. Para cada recurso e para cada perodo de tempo, adicione as horas em todas as atividades, para mostrar o nmero total de horas que o recurso estar alocado ao projeto.
O plano de gerenciamento de recursos normalmente mostrado a seguir do grfico de
Gantt, para facilitar a comparao entre os dois.
ao projeto
71
Criando um plano de comunicao

11 A Gerncia das Comunicaes do Projeto inclui os processos requeridos para garantir
a gerao apropriada e oportuna, a coleta, a distribuio, o armazenamento e o controle bsico das informaes do projeto
11 O plano de comunicao fornece ligaes crticas entre pessoas, ideias e informaes
necessrias para o sucesso. Todos os envolvidos no projeto devem:
22 Estar preparados para enviar e receber comunicaes
22 Entender como as comunicaes afetam o projeto como um todo
Um plano de comunicao necessrio para um fluxo estvel das informaes necessrias
para as vrias entidades e indivduos envolvidos com o projeto, incluindo o patrocinador
do projeto, a alta gerncia, o time de projeto, usurios e fornecedores. O plano responde
questes como quem precisa receber a informao, quando precisa dela e qual o nvel de
detalhamento de que necessita. Mtodos de comunicao formais ou informais podem ser
utilizados na comunicao com as pessoas e entidades envolvidas.
A figura 4.5 detalha o papel do plano de comunicaes na garantia da qualidade e no gerenciamento de riscos. Benefcios de qualidade podem ser obtidos pela coleta e disseminao
da informao sobre os requisitos do projeto e sobre o progresso para membros do time e
stakeholders. O plano de comunicao possui um papel central no gerenciamento de riscos,
ao previnir que alguns riscos aconteam (para, entre outras coisas, satisfazer requisitos de
qualidade) e por comunicar mudanas necessrias para enderear riscos que apareceram.
Riscos
Necessidades
Escopo
Trabalho
Plano de
comunicaes
Alocar
Figura 4.2

11 Por que planejar as comunicaes?
11 Identificar o qu, quando e para quem?
11 Escolhendo entre mtodos formais e informais de comunicao.
72
Por que planejar as comunicaes?

11 Planos de comunicaes suportam a comunicao
11 Para entender a necessidade por um plano de comunicao, o gerente de projetos
deve primeiro entender a necessidade por comunicao em um projeto
11 A comunicao em um projeto deve garantir que as decises tomadas no projeto so
orientadas durante o ciclo de vida do projeto
11 Assim, a primeira razo para se ter um plano de comunicaes garantir que comunicaes importantes ocorram
Para entender a necessidade de um plano de comunicao, o gerente de projetos deve

primeiro entender a necessidade por comunicao em um projeto. A comunicao em um
projeto deve garantir que o gerente do projeto, os membros do time, os patrocinadores,
fornecedores e outras pessoas afetadas pelo projeto possam tomar decises orientadas
durante o ciclo de vida do projeto.
A primeira razo para se ter um plano de comunicaes garantir que comunicaes importantes ocorram. Se a comunicao se torna uma prioridade no projeto, ento o gerente de projetos pode alocar tempo para realizar essa funo crtica, de maneira que comunicaes vitais
no sejam esquecidas. As melhores intenes de se realizar boa comunicao podem simplesmente serem frustradas por detalhes de projeto e necessidades do time de projetos.
11 Por que planejar comunicaes?
11 Planos de comunicao tambm precisam garantir que a comunicao no feita a

mais do que o necessrio
11 Comunicaes excessivas podem acabar diluindo comunicaes importantes
11 Um bom plano de comunicaes decide quem precisa do qu e quando
11 Um plano de comunicaes deve tambm facilitar o trabalho adicional de garantir
que a comunicao seja baseada na necessidade
Planos de comunicao tambm precisam garantir que a comunicao no feita exageradamente, ou mais do que o necessrio. Se forem excessivos, os relatrios de status e as reunies acabaro desperdiando o tempo do comunicador e do receptor. Pior do que gastar
tempo, comunicaes excessivas podem acabar diluindo as comunicaes importantes.
Quando a informao comunicada sem necessidade em uma base regular, os receptores
se desinteressam gradativamente e sinais importantes podem ser perdidos juntamente
com o rudo. Um bom plano de comunicaes decide quem precisa do qu e quando.
Comunicaes baseadas em necessidade podem acabar resultando em mais trabalho para
o gerente de projetos. Um exemplo disso que, em um determinado projeto, em vez de
compartilhar um relatrio detalhado com todos os membros do time, pode ser necessria a
preparao de um relatrio especial para cada parte interessada.
Um plano de comunicaes deve tambm facilitar o trabalho adicional de garantir que a
comunicao seja baseada na necessidade. Se as necessidades de diferentes audincias
so identificadas logo, um modelo pode ser preparado, e suas sees podem ser planejadas
para diferentes audincias. Dessa forma, a informao preparada apenas uma vez, mas
apropriadas. Mesmo quando apenas uma audincia for identificada para uma parte significativa da informao, um modelo pode reduzir o nvel de esforo na criao do relatrio,
por lembrar ao gerente de projeto do que precisa ser endereado no documento, e a forma
como isso deve ser apresentado. Assim, criar ou identificar o formato de um relatrio uma
parte valiosa do plano de comunicao.
Identificar o qu, quando e para quem

11 Como gerente de projeto, voc deve criar um plano identificando os stakeholders, os
tipos de relatrio que eles precisam receber e sua frequncia

Um aspecto importante do plano de comunicao se certificar que os stakeholders apropriados recebem informaes relevantes em intervalos regulares atravs do ciclo de vida do
projeto. Como um gerente de projeto, voc deve criar um plano identificando os stakehol-
relatrios especializados podem ser preparados facilmente, pela seleo das subsees
ders, os tipos de relatrios que eles precisam receber e a frequncia desses relatrios.
73
Escolhendo entre mtodos formais e informais de comunicao

11 H diversas formas de se comunicar requisitos de projeto e status
11 Cada uma dessas formas pode ser apropriada para diferentes tipos de comunicao
Mtodo
Caractersticas
Limitaes
Reunies de
time
Ajuda na interao do time e no

esclarecimento de problemas;
auxilia que o gerente entenda
como determinada informao
foi assimilada pelos receptores.
Gasto excessivo de tempo de

membros que no precisam de
toda informao apresentada ou
esclarecida.
Memorandos
Documentos escritos disponibilizam uma referncia rpida a

problemas de projeto.
Esclarecimento de informao
com certo atraso, e apenas se o
receptor identificar a necessidade
de ler.
Relatrios
Documentos detalhados, tipicamente com dados de apoio,

devem prover dados suficientes
para reviso e avaliao.
Esclarecimento de informao
com certo atraso, e apenas
se o receptor identificar a necessidade.
Apresentaes
Como so formais e organizadas,

permitem que informaes orais
e escritas sejam compartilhadas.
Tende a ser uma forma de comunicao de uma via. Embora haja

a oportunidade para os receptores tentarem esclarecimentos,
h pouca oportunidade da verificao do entendimento deles por
parte do gerente de projetos.
Contatos
por internet/
intranet
(e-mail, listas
de discusso,
fruns)
Combinao de mtodos formais

e informais; permite tanto uma
interao individual quanto uma
sesso de grupo; forma fcil e
rpida de interagir com recursos
remotos.
Necessita que o canal de comunicao esteja funcionando de

maneira confivel.
Contatos informais (telefonemas, visitas

rpidas)
Favorece a interao individual e

esclarecimento; boa habilidade
de verificar entendimento; disponibiliza uma atmosfera casual que
pode acarretar em colaborao
mais evidente.
Mensagens precisam ser repetidas para mltiplas audincias,

se necessrio; ausncia de interao em grupo.
Tabela 4.3
Desenvolvendo um plano de comunicao
A Star Universe Media uma empresa de internet e televiso a cabo que opera nos Estados
Unidos, mas por causa de regulaes do governo atravs da Federal Communications
74
Comission (FCC), s pode disponibilizar o servio em localidades especficas. A empresa

precisa de foco na maximizao de suas capacidades e servios, e ao mesmo tempo reduzir
custos e recursos.
Atualmente, o site hub que atende aos endereos dos clientes que determina as taxas
cobradas, a oferta de produtos, assim como os tcnicos que fazem instalao e manuteno.
Os dados de endereo esto contidos em bancos de dados regionais (vrias localidades geogrficas compem uma regio). Como resultado de vrias aquisies e fuses, uma variedade
de sistemas de pedidos, de instalao e manuteno so usados ao longo do territrio da
Star Universe Media. Cada um desses sistemas acessa somente os dados de endereo de sua
prpria regio. A Star Universe Media atualmente tem 70 escritrios de servio e 100 centros
de instalao de manuteno ao longo dos Estados Unidos. Os grupos de servio ao cliente
so responsveis por realizar pedidos e pela cobrana de seus clientes, enquanto os grupos
de instalao e manuteno so responsveis pela instalao e por reparos para a empresa.
Os escritrios corporativos esto passando por uma grande mudana na empresa por meio
da consolidao dos escritrios de servio ao cliente e centros de instalao e manuteno
(as equipes de instalao permanecero nas suas localidades atuais). Esses escritrios
passaro a se localizar estrategicamente nas reas de Washington D.C., Phoenix, Arizona
e Minneapolis. A empresa quer implantar um sistema nico para o servio ao cliente e um
sistema nico para instalao e manuteno. Os sistemas vo se comunicar uns com os
outros de maneira que as vendas possam abrir uma ordem de instalao, e a instalao
possa comunicar qualquer mudana no pedido para as equipes de vendas e contabilidade.
Como os dois grupos vo precisar acessar os dados de endereo dos clientes, necessrio
tambm um banco de dados de armazenamento de endereos.
Foi requisitado que ambos os sistemas sejam completados concorrentemente, com a
primeira implantao em Minneapolis, a segunda em Phoenix e a ltima em Washington.
O planejamento inicial define que a data de encerramento do projeto ocorrer 36 meses
depois da data de incio.
Como claramente esse projeto grande demais para apenas um gerente de projetos, voc foi
alocado ao projeto de servios ao cliente e outra pessoa foi alocada ao projeto de instalao e
manuteno. A converso do banco de dados ser terceirizada, e voc ter a responsabilidade
de gerenciar o contrato do fornecedor at o encerramento. Tanto voc quanto o outro gerente
do projeto se reportaro a um diretor tcnico, que disponibilizar atualizaes semanais aos
superiores no departamento de TI e tambm para o diretor executivo da Star Universe Media.
O diretor executivo solicitou que ambos os times de projeto incluam na lista de recursos o
gerente de vendas corporativo e o gerente corporativo de instalao e manuteno. Eles vo
indicar algum de seus departamentos para participar em uma base mais formal.
Tambm preciso pensar no treinamento, pois o sistema ser novo para todos os usurios e
muitos deles ainda por cima so novos na empresa. Um pacote de treinamento bem desenvolvido e um cronograma de implantao vo garantir que o seu time tenha uma transio estvel.
A Star Universe Media alocou um responsvel para assuntos relacionados ao oramento do
e elaborar relatrios de custos para a corporao.
Voc e o outro gerente vo acompanhar seus projetos individuais e precisam desenvolver
uma estrutura de reporte que possa ser facilmente combinada em vrios nveis do gerenciamento e individualizada para as necessidades especficas do seu time.
1. Desenvolva um plano de comunicao para a Star Universe Media:
1.1.Identifique ao menos trs audincias de interesse para o projeto.
1.2.Descreva o tipo de informao que precisa ser comunicada (progresso, mudanas
de escopo, custos etc.).
1.3.Liste a frequncia das comunicaes (semanal, mensal, quando necessrio etc.).
projeto. Essa pessoa ter a responsabilidade de gerenciar o oramento, acompanhar custos
75
Audincia
Tipos de informao
Frequncia
Audincia
Tipos de informao
Frequncia
Audincia
Tipos de informao
Frequncia
2. Para cada um dos mtodos de comunicao a seguir, identifique quando e por que voc
usaria tal mtodo:
2.1.Reunies de time
2.2.Relatrios
2.3.Apresentaes
2.4.Contatos informais
3. Discuta os tipos de mecanismos de acompanhamento que sero necessrios nesse
projeto.
4. Liste pelo menos cinco relatrios necessrios para o gerenciamento desse projeto e os
descreva, tendo o cuidado de considerar as necessidades de informao dos principais
stakeholders.
Relatrio 1
Receptores
Descries
Frequncia
Relatrio 2
Receptores
Descries
76
Frequncia
Relatrio 3
Receptores
Descries
Frequncia
Tabela 4.4
Relatrio 4
Receptores
Descries
Frequncia
Relatrio 5
Receptores
Descries
Frequncia
Criando um plano de gerenciamento da qualidade

11 A gerncia da qualidade do projeto inclui os processos requeridos para garantir que o
projeto vai satisfazer as necessidades para as quais foi empreendido

11 Inclui todas as atividades da funo de gerncia geral que determinam as polticas de
qualidade
22 Objetivos e responsabilidades
22 Planejamento da qualidade
22 Controle da qualidade
22 Garantia da qualidade
22 Melhoria da qualidade dentro do sistema de qualidade
O controle da qualidade e o plano de gerenciamento vo garantir a qualidade superior dos
entregveis e um projeto operacionalmente correto. Envolvem tambm a identificao
do que constitui qualidade para o projeto e, ento, o desenvolvimento de mtodos para
mensur-la. Um gerente de projetos pode regularmente monitorar o progresso do projeto
usando mtodos como testes, inspees, reviso a partir de grupos de foco com usurios,
e reunies com os clientes. Um plano slido de gerenciamento da qualidade precisa estar
sendo executado para resolver conflitos e diferenas que possam aparecer no time do
projeto durante seu desenvolvimento. Mtodos como avaliaes, discusses e votao
podem resolver tais problemas.
Os tpicos a seguir sero discutidos:
11 Gerenciamento da qualidade e monitoramento;
11 Desenvolvendo mtricas de qualidade;
11 Monitorando mtricas de qualidade.
Tabela 4.5
77
Qualidade
11 Como saber se um produto bom o suficiente?
11 De acordo com o ISO: Qualidade a conformidade s exigncias

22 Entretanto, o conceito de qualidade subjetivo: alguns avaliam a aparncia do
produto, outros o preo e outros ainda o material com o qual o produto feito
22 O aspecto mensurvel da qualidade o processo
11 As organizaes tm se dedicado a medir a qualidade pela satisfao dos clientes:
qualidade Total
11 O conceito de qualidade total pode ser estendido para projetos, se considerarmos
que qualidade do projeto a satisfao de clientes e tambm dos stakeholders
Algum que esteja determinado a produzir um excelente produto enfrenta dois problemas.
Como saber quando o produto bom o suficiente? Se o produto ainda no for bom o
suficiente, como garantir que os envolvidos saibam disso? A resposta primeira pergunta
permite liberar o release do produto. A resposta segunda pergunta ajuda a evitar o release
de um produto insatisfatrio.
Qualidade a adequao ao uso, a conformidade s exigncias. Essa a definio tcnica
estabelecida pelo International Standardization Organization (ISO), situado na Sua e
responsvel pelas normas de qualidade em diversos setores, no mundo inteiro. Contudo,
quando falamos de qualidade, foroso render-se a definies mais abrangentes.
De acordo com Jlio Lobos, no livro Qualidade atravs das pessoas (1991), qualidade tem a
ver, primordialmente, com o processo pelo qual os produtos ou servios so materializados. Se
o processo for bem realizado, um bom produto final advir naturalmente. A qualidade reside no
que se faz, alis, em tudo o que se faz, e no apenas no que se tem como consequncia disso.
Em outras palavras, todos os processos de uma determinada atividade so importantes; se os
processos forem desenvolvidos com qualidade, o produto final ter qualidade.
Entretanto, se perguntarmos a pessoas leigas o que qualidade?, provavelmente receberemos respostas diferentes. Isso acontece porque o conceito de qualidade est ligado a
sentimentos subjetivos que refletem as necessidades internas de cada um. Muitas pessoas
avaliam a qualidade pela aparncia, outras pensam na qualidade do material do produto,
enquanto outras ainda avaliam a qualidade a partir do preo. Na verdade, existem vrias
dimenses da qualidade.O aspecto objetivo e mensurvel da qualidade o processo,
atravs do qual possvel implantar sistemas como o da ISO-9000, por exemplo.
Entretanto, como as organizaes preocuparam-se em estudar a qualidade nas dimenses
no atingidas pelos processos, surgiu o conceito de qualidade total, muito mais abrangente
e preocupado em estudar a satisfao dos clientes.O conceito de qualidade total pode ser
facilmente estendido para a qualidade de um projeto, se for mensurada a satisfao dos
78
stakeholders com o projeto.
Qualidade de produto
11 Para um produto de qualidade, so necessrias medidas e critrios de identificao
do nvel desejado de qualidade pelo cliente e verificar se tal nvel foi atingido
11 A medio da qualidade do produto conseguida com tcnicas de medio como:
22 Anlises / ensaios
22 Inspees
22 Performance e execuo
11 A partir delas so derivadas mtricas como defeitos, cobertura e desempenho
Especificar os requisitos de modo claro, conciso e passvel de teste apenas parte da
aquisio da qualidade do produto. Tambm necessrio identificar as medidas e os
critrios que sero usados para identificar o nvel desejado de qualidade e determinar se
ele foi atingido. As medidas descrevem o mtodo de capturar os dados usados para avaliar
a qualidade, enquanto os critrios definem o nvel ou o ponto em que o produto atingiu a
qualidade aceitvel (ou inaceitvel).
A medio da qualidade do produto de um artefato executvel conseguida usando-se uma
ou mais tcnicas de medio, como:
11 Anlises / ensaios;
11 Inspeo;
11 Execuo.
Diferentes mtricas so usadas, dependendo da natureza da meta de qualidade da medida. Por
exemplo, em anlises, ensaios e inspees, a meta principal destacar as dimenses de qualidade de confiabilidade e de funo. Defeitos, cobertura e obedincia so as principais mtricas
usadas com essas tcnicas de medio. A execuo, no entanto, pode focalizar a funo, a
confiabilidade ou o desempenho. Portanto, defeitos, cobertura e desempenho so as principais
mtricas usadas. Outras medidas e mtricas vo variar com base na natureza do requisito.
Qualidade de projeto
11 Para obter um projeto de qualidade necessrio colher os conceitos subjetivos de
qualidade daqueles que podem influenciar o projeto, e comparar o progresso do

projeto com esses conceitos
todos os stakeholders acerca de um processo de gerenciamento que cumpra padres

e diretrizes de qualidade
11 Alm disso, possvel medir a qualidade de um projeto atravs da comparao do
estado da execuo com a linha de base (programao inicial) do projeto
11 A qualidade dos artefatos (produto) produzidos por um projeto uma parte componente da qualidade do projeto
A medio da qualidade do projeto conseguida pela coleta de medidas de conhecimento e
de aquisio, e atravs da comparao delas com as expectativas dos stakeholders.
11 O grau de cumprimento de padres de qualidade, diretrizes e implementao de um
processo de gerenciamento previamente aceito pelos stakeholders.
11 O primeiro passo para se obter qualidade em um projeto obter a concordncia de
79
11 O status / estado da execuo do projeto no momento atual em comparao programao original do projeto.
11 A qualidade dos artefatos produzidos pelo projeto (usando as medidas de qualidade do
produto que foram aqui descritas).
A medio da qualidade do projeto conseguida atravs de uma ou mais tcnicas de
medio, como:
11 Progresso: como os casos de uso demonstrados ou os marcos concludos;
11 Variao: as diferenas entre requisitos de equipe, oramentos, programaes planejadas
e reais etc.;
11 Medidas e mtricas de qualidade do produto.
Gerenciamento da qualidade e monitoramento

11 O gerenciamento da qualidade envolve o planejamento, comunicao, monitora-
mento e resposta
11 Durante o planejamento, o gerente de projetos determina os requisitos de qualidade,
que inclui:
22 Como vai comunicar tais requisitos
22 O que ser monitorado e como
22 Quais estratgias de resposta sero usadas em possveis ocorrncias
O gerenciamento da qualidade envolve o planejamento, comunicao, monitoramento e resposta. Durante o planejamento, o gerente de projetos determina os requisitos de qualidade,
como vai comunicar tais requisitos, o que ser monitorado e como, e quais estratgias de
resposta sero usadas em possveis ocorrncias. Esse processo iterativo, e quando aplicado
pode levar a respostas que mudam planos iniciais. J que discutimos anteriormente os outros
elementos do gerenciamento da qualidade, focaremos aqui no monitoramento da qualidade.
importante formalizar o monitoramento da qualidade como parte dos processos de
gerenciamento de projetos pelas mesmas razes que foram dadas para formalizar outros
processos. Se o monitoramento for incorporado como uma atividade do gerenciamento de
projetos, ser necessrio o estabelecimento de requisitos de como e quando a qualidade
ser monitorada, e o tempo e oramento sero alocados para realizar essa atividade atravs
da execuo do projeto. Isso trar vrios benefcios:
11 Atividades tendem a ser completadas se forem planejadas;
11 As tarefas sero completadas de maneira mais fcil, porque rotinas foram estabelecidas;
11 Outros benefcios relacionados ao monitoramento da qualidade, j que uma parcela do
tempo foi dedicada para planejar a sada desse processo.
80
Desenvolvendo mtricas de qualidade

11 O primeiro passo para monitorar a qualidade determinar o que ser avaliado
11 O gerente de projetos precisa fazer o que segue:
22 Identificar o que significa qualidade para esse projeto
22 Desenvolver as mtricas que caracterizam o conceito de qualidade para esse projeto
A equipe de gerncia do projeto deve tambm estar atenta ao fato de que a gerncia
moderna da qualidade complementa a gerncia do projeto. O primeiro passo para monitorar a qualidade determinar o que ser avaliado. Por trabalhar prximo ao patrocinador
do projeto e com o time, e por usar o documento de escopo do projeto, o gerente de projetos precisa reconhecer a importncia de:
11 Satisfao do cliente entender, gerenciar e influenciar necessidades de forma que as
expectativas do cliente sejam satisfeitas. Isso exige a combinao deconformidade com
requerimentos(o projeto deve produzir o que foi dito que produziria) econveninciapara
o uso (o produto ou servio produzido deve satisfazer suas necessidades reais).
11 Preveno em vez de inspeo o custo da preveno de erros sempre muito menor
que o custo para corrigi-los, como demonstrado pela inspeo.
11 Responsabilidade da gerncia o sucesso exige aparticipaode todos os membros da
equipe, mas permanece aresponsabilidadeda gerncia em fornecer os recursos necessrios para se ter xito.
11 Processos dentro de fases o ciclo repetitivo de planejar, fazer, verificar e agir
(plan-do-check-act: PDCA) descrito por Deming e outros.
Fatores como esses ajudam a identificao do que significa qualidade para esse projeto e o
desenvolvimento de mtricas que caracterizam o conceito de qualidade para esse projeto.
Desenvolvendo mtricas de qualidade
11 O gerente de projetos precisa fazer o que segue:

11 Estas tarefas normalmente vo alm dos requisitos tcnicos e funcionais, para
reas como:
22 Facilidade do uso do entregvel
22 Aceitao do entregvel por parte do cliente
22 Aceitao dos mtodos de comunicao do projeto por parte do
patrocinador do projeto
As iniciativas de melhoria da qualidade desenvolvidas pela organizao executora (por
exemplo, Gerncia da Qualidade Total TQM Total Quality Management, Melhorias Contnuas e outras) podem melhorar tanto o gerenciamento do projeto quanto a qualidade do
produto do projeto.
Estas tarefas normalmente vo alm dos requisitos tcnicos e funcionais, para reas como:
11 Aceitao do entregvel por parte do cliente;

11 Aceitao dos mtodos de comunicao do projeto por parte do patrocinador do projeto.
Entretanto, existe uma diferena importante que deve merecer particular ateno da equipe
de gerncia do projeto; a natureza temporria do projeto faz com que os investimentos na
melhoria na qualidade do produto, especialmente a preveno de defeitos e avaliaes,
devem, frequentemente, ficar a cargo da organizao executora, uma vez que o projeto
pode no durar o suficiente para colher as recompensas.
11 Facilidade do uso do entregvel;
81
Assim que mtricas de qualidade sejam identificadas, o gerente de projetos deve imple-
mentar um sistema para monitor-las atravs do ciclo de vida do projeto:

11 Inspees peridicas
11 Verificao de teste
11 Questionrios para os clientes
11 Grupos de foco e reunies para reviso de qualidade
Com a identificao das mtricas de qualidade, o gerente de projetos deve implementar um
sistema para monitor-las atravs do ciclo de vida do projeto. Desenvolver esse sistema
inclui identificar abordagens qualitativas e quantitativas para determinar a extenso na qual
essas mtricas esto sendo aplicadas, incluindo:
11 Inspees peridicas;
11 Verificao de teste;
11 Revises por colegas;
11 Questionrios para os clientes;
11 Grupos de foco;
11 Reunies para reviso de qualidade.
As organizaes empregam um sistema para satisfazer os requisitos dos sistemas internacionais de padro de qualidade, como a ISO 9001. Cada um dos mtodos descritos anteriormente
pode ser empregado para satisfazer uma parte dos requisitos da ISO 9001 nas diferentes
fases do projeto, tais quais a verificao do controle do projeto, validao e revises.
Desenvolvimento de mtricas de qualidade
A CELPE uma empresa pblica de distribuio de energia e iluminao em Pernambuco e
responsvel pela malha eltrica no Grande Recife. O gerente do departamento de transportes e atendimento, responsvel pela frota da CELPE no Recife, aps um processo de
licitao, contatou a sua empresa para projetar um sistema que permita que eles reduzam
custos com manuteno, reviso e abastecimento da frota de mais de 200 automveis,
atravs de controles efetivos de gerenciamento de inventrio.
Seu contato um membro tcnico da equipe do departamento de atendimento ao cliente,
e por causa desse projeto, ela vai passar a reportar diretamente para o gerente do departamento de transportes e atendimento. Nas suas discusses com ela, voc determinou que o
sistema precisa fazer o seguinte:
Prover um inventrio inicial de itens de manuteno de automveis disponveis na CELPE:
pneus, rdios de comunicao, aditivos, limpadores de pra-brisas etc. Esse inventrio
82
decorrncia do processo contnuo de renovao da frota do CELPE.

11 Disponibilizar uma lista de oficinas e postos conveniados.
11 Acompanhar o nmero de automveis disponveis na frota e sua situao de utilizao,
de maneira que possa ser possvel identificar a disponibilidade dos mesmos em situaes
emergenciais (quando muitas ocorrncias estiverem pendentes).
11 Acompanhar o histrico de revises emergenciais (que utilizam o inventrio disponvel),

de revises regulares, consertos e abastecimento para cada um dos automveis na frota,
de maneira que se saiba quando programar revises adicionais, necessidades de abastecimento ( necessria a manuteno de um controle de quilometragem percorrida e
ndices de economia dos automveis) e como antever potenciais problemas em cada um
dos automveis na frota.
11 Acompanhar o custo do trabalho por atendimento, identificando o nmero de horas
necessrias para o deslocamento em cada chamado, alm do nmero e do tipo dos funcionrios necessrios para realizar o trabalho.
11 Obteno de mtricas de eficincia de atendimento, levando em considerao fatores
como tempo de atendimento, anlise do desgaste dos automveis e gastos com abastecimento com o objetivo de melhoria contnua (exemplos: se a frota est sendo usada exclusivamente para a realizao do trabalho, ou saber como os funcionrios esto dirigindo).
1. Identifique o significado de qualidade para esse projeto.
2. Identifique as mtricas de qualidade que podem ser realizadas pelo projeto.
3. Liste os mtodos para monitorar as mtricas de qualidade do projeto.
Criando um plano de gerenciamento do projeto

O desenvolvimento do plano do projeto utiliza as sadas dos outros processos, incluindo
planejamento estratgico para criar um documento consistente e coerente que possa

ser usado para guiar tanto a execuo quanto o controle do projeto
11 Esse processo quase sempre se repete vrias vezes
Por exemplo, o esboo inicial pode incluir recursos genricos e uma sequncia de atividades sem datas, com o tempo, verses subsequentes do plano, recursos especficos e
datas explcitas
A ltima parte da fase do planejamento o desenvolvimento de um plano de projeto e a sua
apresentao aos patrocinadores e stakeholders, para obter sua aprovao e seguir com o
projeto. Um plano bem preparado vai incluir uma lista de atividades, papis e responsabilicontrole de mudana, fatores crticos de sucesso e uma estratgia de encerramento.
O que um plano de gerenciamento de projetos?

Um plano de gerenciamento de projetos:
11 Trata-se de um documento referenciado como de definio de projeto
11 Usado para obter aprovao de patrocinadores e stakeholders
11 Identifica o que precisa ser feito para satisfazer os objetivos do projeto
11 Usa o documento de escopo como uma fundao
dades do projeto, cronograma, recursos necessrios, oramento, entregveis, processos de
83
Um plano de gerenciamento de projetos:

11 usado para obter aprovao de patrocinadores e stakeholders;
11 Identifica o que precisa ser feito para satisfazer os objetivos do projeto;
11 Usa o documento de escopo como uma fundao.
11 Enderea as seguintes reas:
22 Anlise das atividades o que precisa ser feito;
22 Plano de comunicao e estrutura de reporte;
22 Mtodo de acompanhamento do projeto;
22 Sistema de gerenciamento da configurao (controle de verso de documentos);
22 Anlise de requisitos;
22 Gerenciamento de riscos;
22 Gerenciamento dos custos;
22 Planejamento de fornecedores.
Um plano de gerenciamento do projeto tambm referenciado como um documento de
definio de projeto.
Planos de projeto confiveis so realistas, atualizados e revisados frequentemente. O trabalho
detalhado em peas gerenciveis, com horas extras e oramento para contingncia.
Plano de gerenciamento do projeto

Um plano de gerenciamento de projeto uma coleo organizada de documentos de
planejamento de projetos e deve incluir:

11 Documento de escopo (anlise de requisitos)
11 Lista de atividades organizada na EAP
11 Cronograma
11 Plano de gerenciamento de recursos
11 Oramento e gerenciamento de custos
11 Gerenciamento de riscos
11 Lista de entregveis
11 Plano de comunicaes
Um plano de gerenciamento de projeto uma coleo organizada de documentos de planejamento de projetos e deve incluir:
11 Lista de atividades organizada na EAP;
84
11 Cronograma;
11 Plano de gerenciamento de recursos;
11 Oramento;
11 Anlise de riscos;
11 Lista de entregveis;
11 Plano de comunicao.
Um plano de gerenciamento de projeto uma coleo organizada de documentos de
planejamento de projetos e deve incluir:

11 Plano de gerenciamento da qualidade
11 Processo de controle de mudanas (incluindo gerenciamento da configurao)
11 Plano de gerenciamento de fornecedores
11 Papis e responsabilidades do projeto
11 Fatores crticos de sucesso
11 Mtricas do projeto
11 Plano de encerramento do projeto
Exerccios de fixao
1. O que identificado em uma EAP?
2. Quais os quatro principais componentes no gerenciamento de riscos?
3. Descreva caminho crtico.
4. Quais os quatro principais componentes de um contrato com fornecedores?
5. Descreva trs mtodos de comunicao em um projeto.
85
86
5
Execuo, monitoramento e
controle
indivduos e grupos com os quais ser necessrio negociar durante o projeto.
Identificar e explicar estratgias para manter entregveis de qualidade. Identificar as
necessidades de membros do projeto. Gerenciar problemas individuais de performance.
Identificar estratgias para prevenir scope creep (desvios de escopo). Descrever as
condies para iniciar um processo de controle de mudanas.
Scope Creep. Controle integrado de mudanas
conceitos
Execuo. Negociao. Monitoramento e Controle. Desempenho e Performance.
1. Por que o acompanhamento de projeto importante?
2. Liste duas formas de acompanhar um projeto.
3. Liste duas razes pelas quais um projeto pode acabar atrasando por causa do gerenciamento de recursos.
4. O que deve ser feito para se manter a qualidade dos entregveis de um projeto?
5. Como as mudanas de um projeto devem ser endereadas durante a fase de execuo?
Captulo 5 - Execuo, monitoramento e controle
objetivos
Identificar atividades relacionadas ao acompanhamento do projeto. Identificar os
87
Introduo
11 Em projetos tradicionais, a fase de execuo tipicamente a mais longa.

11 Fase em que os entregveis do projeto so construdos e apresentados para o cliente,
visando a sua aceitao.
11 Para garantir que os requisitos dos stakeholders sero satisfeitos, o gerente do
projeto monitora e controla as atividades, recursos e gastos necessrios para a construo de cada entregvel.
11 Recomendaes e processos de gerenciamento precisam ser realizados para garantir
a execuo aceitvel do projeto.
Estudaremos nessa sesso a execuo dos planos de projeto. A primeira parte da sesso trata
do acompanhamento dePlanejamento
projetos e da resoluo de problemas. O aluno ser introduzido ao
conceito do gerenciamento de recursos e aos problemas que podem ocorrer no cronograma.
Sero discutidos mtodos de acompanhamento de cronograma atravs de indicadores de
progresso, e apresentados problemas de gerenciamento da qualidade, incluindo testes para
Denio de
Execuo
a garantia da qualidade. Tambm veremos problemas
relacionados ao time de projetos e
Escopo
a necessidade de liderana, identificao das necessidades dos membros do projeto e o

gerenciamento de problemas individuais de performance e do time. A sesso finalizada com
estudo sobre o gerenciamento de um processo de controle de mudanas e seus efeitos no
projeto como um todo.
Encerramento
1. Iniciao
2. Planejamento
3. Execuo
5. Enceramento
Figura 5.1
Execuo dos
planos de projeto.
Execuo, monitoramento e controle

11 H uma expresso que diz que um projeto bem planejado j est 50% concludo.
11 Isso pode at ser verdade, mas o gerente de projeto deve manter o foco para se certificar de que o projeto ser de fato concludo.
11 O gerente de projetos deve garantir que:
22 O plano do projeto apropriado e executado adequadamente.
22 Quando necessrio, o plano deve ser modificado para se tornar apropriado.
88
A execuo o processo bsico de realizao do plano do projeto, onde ser gasta a maior
parte do oramento do projeto.H uma expresso que diz que um projeto bem planejado j
est 50% concludo. Isso pode at ser verdade, mas o gerente de projetos deve se concentrar para se certificar de que o projeto ser de fato concludo. Nesse processo, o gerente e a
equipe de gerncia do projeto devem coordenar e direcionar as diversas interfaces tcnicas
e organizacionais do projeto. Alm disso, o processo mais diretamente afetado pela rea
de aplicao do projeto, pois nele que o produto do projeto criado.
O gerente de projetos deve garantir que o plano do projeto apropriado; que executado adequadamente e que, quando for necessrio, o plano ser modificado para se tornar apropriado.
Esse o processo de monitoramento e controle, que deve acontecer em paralelo execuo.
11 A execuo no o mero cumprimento do plano.
11 Monitorar e controlar acompanhar o progresso do projeto:

22 Garantir que todos os marcos sero satisfeitos.
22 Garantir que os entregveis sero aceitos.
22 Garantir que o projeto permanecer dentro dos limites de escopo, tempo e custos.
11 O plano poder ser modificado durante a execuo para englobar novas informaes
A execuo do projeto no deve ser entendida como o simples cumprimento do plano.
O desempenho do projeto deve ser continuamente monitorado atravs da comparao
do trabalho planejado com aquele efetivamente realizado, para que as aes corretivas
possam ser tomadas. Enquanto o projeto avana, importante acompanhar o seu progresso, garantindo que todos os seus marcos sero satisfeitos, seus entregveis aceitos, e
que o projeto permanece dentro dos limites de escopo, tempo e custos. Como o planejamento do projeto um processo iterativo, o plano precisa ser modificado durante a execuo para englobar novas informaes, se for o caso. Para auxiliar essa anlise, dever
ser feita uma previso peridica do custo final e dos resultados do cronograma.
Monitoramento e controle do projeto

11 Durante todo o ciclo de vida do projeto, necessrio garantir sua evoluo
dentro do cronograma e que os recursos alocados a ele esto sendo utilizados

de maneira suficiente.
11 Para isso, o gerente de projetos precisa:
22 Coletar informaes de desempenho do projeto.
22 Fornecer aos interessados informaes sobre como os recursos esto sendo utilizados para alcanar os objetivos do projeto.
11 O monitoramento e controle do projeto deve fornecer informaes do escopo, cronograma, custo e qualidade.
11 Muitos projetos tambm exigem informaes de risco e aquisies.
Um componente muito importante da gesto de projetos o monitoramento e controle do

projeto, garantindo sua evoluo dentro do cronograma, e que os recursos alocados a ele
esto sendo utilizados de maneira eficiente. O processo de acompanhamento do projeto
comea com a identificao das atividades de progresso do projeto.
Atividades de acompanhamento do projeto

11 As decises que levam a um encerramento bem-sucedido de um projeto so baseadas no conjunto de informaes que o gerente de projetos possui atravs dos
relatrios de status.
11 inaceitvel descobrir que os relatrios de status no so corretos.
11 Os relatrios podem ser preparados de forma abrangente ou baseados em excees.
89
Mesmo um projeto bem gerenciado, com objetivos bem definidos, recursos adequados e
amparado por um plano lgico, pode falhar se no tiver as informaes adequadas. As decises que levam a um encerramento bem-sucedido de um projeto so baseadas no conjunto
de informaes que o gerente de projetos possui atravs dos relatrios de status. Esses
relatrios e as tarefas de acompanhamento permitem ao gerente de projetos o entendimento mximo sobre o que est acontecendo no ambiente de projeto em um determinado
momento, de maneira que possa fazer ajustes necessrios ao cronograma do projeto.
11 Relatrios primrios de monitoramento e controle de um projeto:
22 Relatrio de status do projeto.

22 Relatrio de variao do oramento.
11 O relatrio de status precisa conter as informaes principais de acompanhamento
que podero ser usadas para documentar o progresso do trabalho de acordo com o
plano de projetos.
aceitvel que durante a fase de planejamento o gerente de projetos no tem certeza do
momento exato da necessidade de recursos. Entretanto, devido dependncia do projeto
acerca de informaes de status, inaceitvel descobrir que os relatrios de status no
esto corretos.
Os dois relatrios de status descritos na tabela 5.1 so as ferramentas mais comumente
usadas em organizaes para acompanhar o progresso peridico do projeto. Os relatrios
primrios de acompanhamento de projeto so:
rea do projeto
Questes
Relatrio de status
do projeto
Documenta o status do projeto, esforos de desenvolvimento e progresso em

atingir os requisitos do projeto.
O gerente de projeto documenta a eficincia da relao entre progresso real e
progresso esperado, nas diversas reas do projeto.
Relatrio de variao
do oramento
Documenta os gastos previstos e tambm os gastos reais do projeto, visando

identificar variaes.
As variaes precisam ser identificadas, documentadas, explicadas e resolvidas,
se possvel.
Acompanhamento de problemas
11 Os relatrios de status e varincia devem ser revisados em intervalos agendados.
11 Ajudam a monitorar o status do projeto, o progresso realizado e os problemas
experimentados.
11 Os gestores de projetos precisam ter cuidado com projetos orientados a monitoramento de problemas:
22 O problema com essas tcnicas que tendem a ser reativas.
90
22 A informao s se torna disponvel para o gerente de projeto dias aps o esforo

j ter sido realizado.
22 Os relatrios e as anlises tendem dar foco a problemas existentes, em vez de
antecipar problemas em potencial.
Tabela 5.1
Os relatrios de status e varincia so tipicamente revisados em intervalos agendados,

para monitorar o status do projeto, o progresso realizado e os problemas experimentados.
Para todo problema existente no projeto, necessria a identificao e o emprego de aes
corretivas. Uma ao corretiva tudo aquilo que feito para compatibilizar o desempenho
futuro da programao com o plano do projeto. Aes corretivas na rea de gerncia do
tempo, por exemplo, frequentemente envolvem presteza: aes especiais tomadas para
garantir a concluso da atividade em tempo ou com o mnimo de atraso possvel, e tambm
com frequncia requerem anlise da raiz da causa para identificar o motivo da variao.
Um cronograma de recuperao pode ser planejado e executado para atividades delineadas
mais tarde no cronograma, e no somente para enderear a atividade causadora do desvio.
Essas tcnicas tendem a ser reativas, pois:
11 A informao, particularmente sobre variaes, s se torna disponvel para o gerente de
projeto dias aps o esforo j ter sido realizado;
11 Os relatrios e as anlises tendem dar foco a problemas existentes, em vez de antecipar
problemas em potencial.
11 As tcnicas de monitoramento formais precisam ser suplementadas com comunica-
es informais e contnuas.
11 Membros do time de projetos precisam ser educados a pensar como gerentes de
projeto e tentar antecipar problemas.
11 Outros mtodos devem ser empregados para garantir a confiabilidade dos relatrios,
tais como o mtodo do valor agregado.
As tcnicas de acompanhamento formais precisam, portanto, ser suplementadas com
comunicaes informais e contnuas entre o gerente de projetos e o time de projetos.
Membros do time de projetos precisam ser educados a pensar como gerentes de projeto e
tentar antecipar problemas.
Todos os relatrios formais de projeto devem ser suplementados com comunicaes informais para se obter um panorama realista da dinmica do progresso do projeto. A fraqueza
dos relatrios que no mostram tendncias que eles no ajudam na predio da performance futura. Usar somente esses relatrios seria como dirigir um carro usando apenas a
viso do retrovisor.
11 Um projeto estimado em R$ 100.000,00 e concludo pela metade tem um valor
agregado de R$ 50.000,00.
11 Se apenas um tero das atividades foram de fato concludas e metade do oramento
j foi gasto, o valor agregado ento foi de apenas R$ 33.000,00 contra um custo incorrido de R$ 50.000,00.
22 Varincia negativa de R$ 17.000,00.
11 Valor agregado serve para quantificar o progresso do projeto em termos monetrios.
O valor agregado compara estimativas originais de projeto com o progresso real para
mostrar se os custos incorridos esto dentro, a seguir ou acima do oramento. A anlise do
valor agregado, em suas vrias formas, o mtodo mais comumente utilizado na medio
do desempenho. Inclui medies de escopo, custo (ou recursos) e cronograma para auxiliar
a equipe de gerncia do projeto na avaliao do desempenho do projeto.
Valor agregado
91
Por exemplo, um projeto estimado em R$ 100.000,00, que j foi concludo pela metade
(tanto em termos de tempo quando de atividades finalizadas) tem valor agregado de
R$ 50.000,00. Se apenas um tero das atividades foram de fato concludas, e metade do
oramento j foi gasto, o valor agregado ento foi de apenas R$ 33.000,00 contra um custo
incorrido de R$ 50.000,00, o que gera varincia negativa de R$ 17.000,00. Dessa forma,
uma indicao de que o projeto est acima do orado e atrasado em termos de finalizao
de atividades.
Gerenciando recursos
Uma parte significativa do gerenciamento de recursos controlar o cronograma e garantir
que o projeto no est apresentando uma tendncia de atraso. Para isso, existe um mtodo
largamente utilizado: o mtodo da luz verde e vermelha. No caso de um atraso no cronograma, o gerente de projetos responsvel por negociar com as diversas partes envolvidas,
incluindo o patrocinador do projeto, o time do projeto e fornecedores.
Atrasos de cronograma
O gerente de projetos responsvel por analisar as causas de atrasos no cronograma.
11 Problemas de comunicao.
11 Falta de treinamento.
11 Especificidades de ambiente.
11 Falta de recursos adequados.
11 Expectativas no realistas.
A anlise de variao do cronograma o elemento-chave para o controle do tempo. A comparao das datas (de incio e fim do projeto) estabelecidas inicialmente com as datas realizadas
pode fornecer informaes teis para a deteco de desvios, e para a implementao de
aes corretivas nos atrasos. A flutuao da variao tambm um componente essencial de
planejamento para avaliar o desempenho ou tempo do projeto. Uma ateno particular deve
ser dispensada para atividades crticas e subcrticas, como a anlise dos caminhos subcrticos
para definir a melhor execuo.
O gerente de projetos responsvel por analisar as causas de atraso no cronograma.
Algumas causas podem ter relao com outros aspectos do projeto, como:
11 Plano de comunicao ineficiente;
11 Qualificao insatisfatria do time do projeto;
11 Ausncia de recursos adequados para a realizao do projeto;
11 Problemas de hardware, software ou em qualquer material necessrio ao cumprimento
do projeto dentro do prazo.
92
importante tambm realizar anlises do ambiente do projeto para considerar a anlise de

causas de atraso de cronograma. Pode acontecer de os membros do time saberem o que fazer
e como fazer, mas no conseguirem fazer devido a condies no ambiente de trabalho. Tambm
ocorrem problemas por causa das expectativas no realistas alimentadas pelos stakeholders,
isto , quando o time do projeto se compromete a cumprir estimativas impraticveis.
O valor agregado uma

tcnica de controle de
gerenciamento de
projetos que permite
que o gerente de
projeto quantifique o
progresso do projeto
em termos financeiros.
Mtodo do sinal vermelho/sinal verde

11 Abordagem simples para o gerenciamento de projetos.
11 Baseada nas cores de sinal de trnsito (verde, amarelo e vermelho).

22 Verde: o projeto vai bem.
22 Amarelo: o projeto est consumindo a folga.
22 Vermelho: folga consumida; o projeto ser concludo com atraso ou estourando o
oramento.
11 Tipicamente, 70% dos projetos de TI ficam vermelhos pelo menos uma vez nos primeiros seis meses de execuo.
Trata-se de uma abordagem simples para o gerenciamento de projetos, baseada nas cores
de um semforo de trnsito: verde, amarelo e vermelho. Durante a atividade de planejamento, uma folga de contingncia adicionada ao plano aps cada marco crtico do projeto.
Os relatrios reportam o projeto das seguintes formas:
11 Verde: o projeto no est consumindo a folga e, assim, esperado que seja concludo
dentro do tempo e do oramento previstos;
11 Amarelo: o projeto est consumindo folga. O patrocinador e o gerente do projeto devem
avaliar a situao e tomar aes como:
22 Arranjar mais fundos e uma nova data de concluso, o que faz necessria uma justificativa de negcios forte o suficiente para suportar essas mudanas;
22 Limitar o escopo remover requisitos e balancear o plano;
22 Aceitar o consumo da folga, e consequentemente o risco de falha na concluso do
projeto no prazo e dentro dos custos programados.
Normalmente, 70% dos

projetos ficam no
vermelho pelo menos
uma vez nos primeiros
6 meses. Isso acontece
quase sempre por
causa de um fenmeno
chamado scope creep
(desvios de escopo).
Aps 18 meses, a
probabilidade de
entrega do projeto em
tempo e dentro do
oramento melhora em
at 4 vezes.
11 Vermelho: o projeto j consumiu a folga e ser concludo com atraso ou estourando o

oramento. O patrocinador deve disponibilizar mais fundos e uma nova data, ou ento
limitar o escopo. Comits de anlise de projeto devem cancelar projetos que permaneam no vermelho.
Tentando resolver atrasos de cronograma
Durante esse exerccio, o aluno discutir mtodos que podem ser usados para enderear
atrasos de cronograma, considerando o mtodo do sinal vermelho/sinal verde.
Considere algumas das aes descritas no mtodo do sinal vermelho/sinal verde e desenvolva mtodos para enderear atrasos de cronograma.
Negociao
11 O endereamento de atrasos de cronograma requer um processo de negociao.
11 necessrio ter domnio sobre o projeto e habilidade para descrever o valor da proposta, alm de responder a perguntas sobre risco e retorno.
11 O gerente de projetos deve saber com quem negociar.
Atrasos de cronograma normalmente requerem a realizao de um processo de negociao
para se obter recursos adicionais ou para ajustar requisitos.
93
O gerente de projetos deve estar atualizado com as boas prticas de negociao. necessrio ter domnio sobre o projeto e possuir habilidade para descrever o valor da proposta,
alm de estar preparado para responder a perguntas sobre risco e retorno.
Negociao com fornecedores
11 O gerente de projetos deve garantir que os fornecedores entreguem os itens
necessrios para satisfazer os termos do contrato.

11 Os pagamentos dos fornecedores devem ser realizados o mais rpido possvel, assim
que os entregveis tenham sido aceitos.
O gerente de projetos deve garantir a entrega dos itens necessrios pelos fornecedores para
satisfazer os termos do contrato. Os pagamentos dos fornecedores devem ser realizados o
mais rpido possvel, assim que os entregveis tenham sido aceitos. Assim, a responsabilidade por uma entrega adequada, em tempo e com qualidade, do fornecedor.
Se houver alguma dificuldade na definio dos termos de aceitao (qualidade ou nmero
de itens), talvez seja preciso negociar com os fornecedores o valor dos itens e esclarecer que
outros itens do projeto no sero afetados.
Negociao de problemas por atrasos de cronograma
Considere que voc faz parte de uma organizao de TI que projeta sistemas para equipes
de vendas. Para se especializar em sistemas dessa categoria, a corporao decidiu reestruturar a parte de desenvolvimento (TI) e separ-la do setor de documentao e levantamento
de requisitos. O entendimento por trs disso que TI no est suficientemente perto do
negcio de vendas para identificar suas necessidades reais. Assim, h sempre duas equipes
trabalhando nos projetos de vendas: a equipe de TI e a equipe de Automao de Marketing e
Suporte (AMS), que passou a ser responsvel pela anlise de requisitos. Os membros dessas
equipes respondem cada um a um lder de projetos, e participam das reunies quando
necessrio. Esses lderes, por sua vez, reportam para voc, o gerente de projetos de TI.
A sua equipe responsvel por reportar o progresso do projeto para a sua gerncia snior,
e a equipe AMS por reportar para a gerncia snior dele, assim como para o patrocinador do
projeto, os stakeholders corporativos e a gerncia snior corporativa.
Atualmente, as duas equipes esto trabalhando em um sistema de pedido de vendas de
alta visibilidade, concebido para automatizar o processo de pedidos para os produtos e
servios oferecidos pela empresa. Para garantir o fluxo dos pedidos, o sistema precisar se
comunicar com outros sistemas especficos de outros departamentos dentro da corporao.
Seu time de projeto possui representantes de cada um dos sistemas, mas como uma das
equipes no teve tempo suficiente para ajudar no planejamento das interfaces, um fornecedor que j havia trabalhado com esse sistema especfico foi contratado.
Os objetivos do novo sistema de vendas so apoiar o objetivo de 98% de garantia do fluxo dos
pedidos dos produtos suportados entre os vrios sistemas interdepartamentais e eliminar a
maioria dos processos manuais exigidos pelo fluxo atual de pedidos.
Todos os requisitos foram levantados e, aps uma anlise detalhada, sua equipe identificou que
alguns dos requisitos no podem ser satisfeitos no perodo de tempo planejado. Na sua estimativa, o escopo do projeto deve ser reduzido. Alm disso, um dos membros precisou ajudar
a equipe AMS a completar o documento de requisitos dentro do prazo, o que ter impacto no
cronograma geral do projeto e atrasar o cronograma individual desse membro do seu time.
94
O fornecedor trabalhou no projeto e notificou que um dos seus membros principais

adoeceu e precisou se ausentar; a perda dessa pessoa colocou em risco o cumprimento dos
prazos do projeto.
1. Identifique os indivduos que precisam ser contactados para enderear cada uma das
causas do atraso do cronograma e as solues.
2. Descreva como voc negociaria os termos com o fornecedor para garantir que o projeto
continue.
Gerenciando a qualidade
11 O controle da qualidade envolve o monitoramento dos resultados especficos
do projeto.
11 Determina se os resultados esto de acordo com os padres de qualidade relevantes.
11 Identifica formas de eliminao das causas de resultados insatisfatrios.
11 O gerenciamento da qualidade deve ser realizado durante todo o projeto.
22 Os resultados do projeto incluem tanto os resultados doprodutoquanto os resultados dogerenciamento do projeto, como desempenho do custo e do prazo.
Produzir entregveis de qualidade requer um constante gerenciamento da qualidade ao
longo de todo o projeto e um dos principais processos de Monitoramento e Controle do
projeto. O gerenciamento da qualidade comea com um planejamento efetivo, que usa os
processos apropriados e os padres da indstria durante as fases de execuo do projeto,
e eventualmente o teste e a verificao dos componentes do sistema antes de passar para
o prximo estgio no processo. O teste completo inclui o teste de componentes do sistema
fatores importantes no gerenciamento e garantia da qualidade, que precisam ser concludos
antes da implantao do sistema.
Estratgias para manter a qualidade dos entregveis
11 O gerenciamento da qualidade existe para prevenir e minimizar erros durante a
vida do projeto.
11 A falta de garantia da qualidade uma causa frequente de atrasos no cronograma.
11 A qualidade obtida atravs de um plano adequado e da utilizao de processos
apropriados enquanto o projeto estiver acontecendo.
11 Exemplo: padres de desenvolvimento e testes de qualidade.
em diversos cenrios e condies. A documentao do usurio, treinamento e suporte so
95
O gerenciamento da qualidade existe para prevenir e minimizar erros durante o tempo

de vida do projeto. Falta de garantia da qualidade uma causa frequente de atrasos no
cronograma. A qualidade obtida atravs de um plano adequado e da utilizao de processos apropriados enquanto o projeto estiver acontecendo, e tambm suportada pela
verificao e reviso do resultado de cada atividade, antes da passagem para a atividade
seguinte. Aes que podem ajudar a manuteno da qualidade do projeto incluem a
aplicao de padres de desenvolvimento, usando avaliao qualitativa e quantitativa e
mtodos de teste, alm da criao e promoo do uso de canais de comunicao eficientes.
11 Padres de desenvolvimento aplicados atravs de componentes de codificao e
documentao da fase de execuo do projeto ajudam na garantia de que as sadas

das atividades so aderentes aos objetivos do projeto.
11 Alguns padres existentes:
22 CMMI(anteriormenteCMM).
22 SPICE.
22 ISO 12207.
22 MPS/Br.
Umprocesso de desenvolvimento de software um conjunto de atividades, parcialmente
ordenadas, com a finalidade de se obter um produto de software. estudado dentro da
Engenharia
de software
rea deengenharia de software, sendo considerado um dos principais mecanismos para

se obtersoftware de qualidadee cumprir corretamente os contratos de desenvolvimento,
sendo uma das respostas tcnicas adequadas para garantir que as sadas das atividades so
aderentes aos objetivos do projeto.
O processo de desenvolvimento de software tem sido objeto de vrios padres, que visam
a certificao de empresas como possuidoras de um processo de desenvolvimento, o que
garantiria certo grau de confiana aos seus contratantes. Padres de desenvolvimento
podem incluir:
11 Planos estruturados;
11 Padres e modelos;
11 Programao estruturada;
11 Programao modular e orientada a objetos.
11 Testes so uma forma de verificao da performance e da correspondncia entre os
requisitos e o que foi de fato implementado
11 Mtodos de teste incluem:
22 Anlise de falhas.
96
22 Algoritmos de verificao de erro.

22 Testes de software e hardware (automticos ou manuais).
33 Testes funcionais.
33 Compatibilidade de hardware.
33 Testes de usabilidade.
33 Comparao de performance e funcionalidade atravs de benchmarks.
rea da computao
que especifica, desenvolve, faz a manuteno
e cria sistemas de
software.
Oteste do software ainvestigaodosoftwarea fim de fornecer informaes sobre

suaqualidadeem relao ao contexto em que deve operar, o que inclui o processo de
utilizar o produto para encontrar seus defeitos. Testes so uma forma de verificao da
performance e da correspondncia entre os requisitos e o que foi de fato implementado.
Existem outras formas de verificao, que podem incluir o exame de documentos e cdigos,
alm de avaliaes qualitativas.
Realizar o teste de entregveis de projeto diversas vezes durante a execuo ajuda a garantir
que os resultados das atividades funcionem efetivamente com os outros componentes do
sistema. Resultados de teste e outras verificaes do projeto devem ser formalmente revisados e aprovados durante a execuo do projeto.
O teste um processo realizado pelo testador de software, que permeia outros processos
daengenharia de software, e envolve aes que vo dolevantamento de requisitosat a
execuo do teste propriamente dito. Mtodos de teste incluem:
11 Anlise de falhas;
11 Algoritmos de verificao de erro;
11 Testes de software e hardware (automticos ou manuais).
Uma comunicao clara imprescindvel para tratar problemas que no foram inicialmente previstos, alm de ser, por si s, o mecanismo que o gerente do projeto possui para
acompanhar os entregveis do projeto e sua qualidade. Sem canais de comunicao claros,
especialmente na rea da garantia da qualidade, o gerente de projetos no pode responder
adequadamente a problemas ou desafios.
Testes de qualidade
11 H muitos mtodos de testes de qualidade que podem ser aplicados durante a fase
de desenvolvimento.
11 Podemos citar alguns a seguir:
22 Testes funcionais.
22 Compatibilidade de hardware.
22 Testes de usabilidade.
22 Comparao de performance com benchmarks.
22 Comparao de funcionalidade com benchmarks.
Testes bem planejados e automatizados permitem execues de testes em grande escala,

com rapidez e preciso, detectando as no conformidades do projeto, e iniciando as correes pela equipe de desenvolvimento o mais breve possvel. Muitos mtodos de testes de
qualidade podem ser aplicados durante a fase de desenvolvimento. necessrio analisar
tanto o tipo do projeto quanto a fase em que o projeto se encontra, para escolher entre uma
abordagem ou outra. Testes em sistemas e documentaes reduzem os riscos da ocorrncia
de defeitos do software no ambiente de produo (onde so encontrados pelo cliente),
contribuindo para a qualidade dos sistemas. Se os defeitos forem encontrados antes da
implantao do sistema, o custo da correo ser muito menor do que se os defeitos forem
encontrados durante a fase de produo.
22 Casos de uso.
97
Podemos citar algumas abordagens de teste a seguir:

11 Testes funcionais, que executam as funcionalidades do sistema como um todo para
validar suas funes, com o acompanhamento de cenrios elaborados (casos de teste)
por um analista de testes em um ambiente de testes;
11 Compatibilidade de hardware;
11 Testes de usabilidade;
11 Comparao de performance com benchmarks;
11 Comparao de funcionalidade com benchmarks;
11 Casos de uso.
O grande desafio das empresas realizar projetos com qualidade, em um curto espao de
tempo, com baixo custo e atendendo s expectativas do cliente com o produto desenvolvido, ou seja, atendendo aos seus requisitos. Realizar testes dentro de um processo com
metodologia prpria o grande X da questo. Os testes tm por finalidade agregar qualidade ao produto, podendo tambm fazer uma medio dessa qualidade em relao aos
defeitos encontrados, pois caso sejam encontrados poucos defeitos, mais confivel ser o
software. Com os testes possvel tambm antecipar a descoberta de falhas e incompatibilidades, reduzindo o custo do projeto.
Garantia da qualidade durante a implantao

11 No se pode considerar um projeto de TI encerrado no final do esforo de
desenvolvimento.
11 necessrio dar suporte durante a implementao das seguintes fases:
22 Documentao do sistema.
22 Documentao tcnica para manuteno.
22 Treinamento de usurios.
22 Arquivos de ajuda integrados.
22 Suporte de help desk.
A garantia da qualidade consiste em todas as atividades planejadas e sistemticas implementadas dentro do sistema de qualidade, buscando assegurar que o projeto satisfar os
padres relevantes de qualidade. Ela deve ser realizada durante todo o projeto. Antes da
elaborao das sries ISO 9000, as atividades descritas no planejamento da qualidade eram
claramente includas como parte da garantia de qualidade.
No se pode considerar um projeto de TI encerrado ao fim do esforo de desenvolvimento.
J em uma fase final do projeto, o controle de qualidade monitora seus resultados e faz
a comparao com os valores pretendidos, a fim de buscar solues imediatas para os
98
resultados insatisfatrios. nessa fase que os equipamentos e materiais que no esto de

acordo com os padres estabelecidos so rejeitados e substitudos, evitando desperdcio
com trocas posteriores.
Aplicabilidade de mtodos de teste para um projeto de desenvolvimento
Seu time vai projetar um sistema para uma unio de crdito local (empresa que facilita
emprstimos bancrios), com o objetivo de permitir que seus membros possam acessar
via web informaes de conta, alm de realizar transaes como visualizao do status da
conta, transferncia de fundos entre contas e pagamento de contas on-line. imperativo
que cada usurio veja apenas as capacidades de acesso de seu tipo de conta; por exemplo,
se um cliente no tiver a conta Premier, a opo Cheques Premier no deve ser visualizada
na tela desse usurio.
O objetivo da unio de crdito em disponibilizar esses servios para os seus clientes permanecer competitiva no negcio bancrio, mantendo seus clientes atuais e aumentando sua
base de clientes. Seu time identificou que para concluir esse projeto, um web site precisa
ser desenvolvido. O sistema deve acessar e recuperar bancos de dados legados e deve ser
percebido como uma ferramenta rpida e de fcil usabilidade. A aplicao deve recuperar e
atualizar dados, assim como as funcionalidades apropriadas devem estar disponveis para
os clientes da unio de crdito, permitindo que completem suas transaes financeiras.
Outras tarefas importantes que podem ser trabalhadas:
11 Desenvolvimento da documentao do sistema;
11 Documentao tcnica para manuteno;
11 Treinamento de usurios;
11 Elaborao de arquivos de ajuda;
11 Planejamento de suporte de help desk.
1. Descreva como cada um dos mtodos de teste a seguir pode ser aplicado no projeto de
criao do website da unio de crdito:
Mtodo de teste
Projeto
Funcional
Teste de usabilidade
Comparao de
funcionalidade
Casos de uso do usurio
Tabela 5.2
2. Descreva possveis mtricas de garantia da qualidade que podem ser viveis para a
implantao do sistema e para a transferncia do projeto para o pessoal de sistemas.
Comparao de
performance
99
Gerenciando o time do projeto

11 Gerenciar um time de projetos uma parte crtica das responsabilidades de um
gerente de projetos.
11 Um gerente de projetos precisa estar prximo de sua equipe para identificar
potenciais problemas relacionados s necessidades pessoais e de negcio de cada
membro do time.
Esse o processo necessrio para monitorar e controlar o desempenho dos membros da
equipe, fornecer feedback, resolver problemas e coordenar mudanas para melhorar o desempenho do projeto. Gerenciar um time de projetos uma parte crtica das responsabilidades
de um gerente de projetos, que precisa trabalhar de maneira prxima ao time para identificar
potenciais problemas relacionados s necessidades pessoais e de negcio de cada membro do
time. O gerente de projetos precisa ter certeza de que, caso essas necessidades no possam ser
atendidas, elas no atrapalham o progresso do projeto. As informaes sobre o andamento das
atividades do projeto que esto sendo executadas para realizar o trabalho devem ser coletadas
rotineiramente como parte da execuo do plano de gerenciamento do projeto.
11 A participao ativa do gerente nas atividades do projeto:
22 Ajuda a manter alta a moral do time.

22 Permite que responda a problemas antes que se tornem impedimentos para o
progresso do projeto.
11 Esse tipo de abordagem garante:
22 Um gerenciamento de conflitos bem-sucedido.
22 Maior produtividade e relaes de trabalho mais positivas.
11 Quando gerenciadas adequadamente, as diferenas de opinio so saudveis e
podem aumentar a criatividade e melhorar a tomada de deciso.
11 A liderana de um gerente de projetos ajuda a manter:
22 Um fluxo consistente de comunicao.
22 O cronograma ajustado.
22 Os custos controlados.
A participao ativa do gerente do projeto nas atividades de projeto durante a execuo
ajuda a manter alta a moral do time e uma estratgia efetiva de liderana de equipes.
Permite tambm que o gerente de projetos responda a problemas de performance antes
que se tornem um obstculo ao progresso do projeto, sendo uma estratgia significativa
para o monitoramento e controle.
Um gerenciamento de conflitos bem-sucedido resulta em maior produtividade e relaes de
trabalho mais positivas. Fontes de conflito incluem recursos escassos, prioridades na elaborao de cronogramas e estilos pessoais de trabalho. Regras bsicas da equipe, normas de
grupo e prticas slidas de gerenciamento de projetos, como planejamento da comunicao
e definio de funes, reduzem a quantidade de conflitos.A importncia do papel de um
gerente de projetos no apenas a de coordenar o projeto em sua totalidade, mas tambm
de ser um lder que motive o time de projetos. A liderana de um gerente de projetos ajuda a
manter um fluxo consistente de comunicaes, o cronograma, os custos controlados.
O lder deve saber gerenciar as diferenas de opinio entre os membros do time, de forma
que sejam resolvidas de maneira saudvel e possam contribuir com o aumento da criatividade e com a qualidade da tomada de deciso.Quando as diferenas se tornam um fator
100
negativo, os membros da equipe do projeto so os primeiros responsveis por encontrar

uma resoluo para o conflito. Se o conflito aumentar, o gerente de projetos dever atuar
como facilitador de uma resoluo satisfatria. O conflito dever ser tratado no incio e
geralmente em particular, atravs de uma abordagem direta e colaborativa. Se o conflito
continuar, ser necessrio empregar procedimentos cada vez mais formais, inclusive o uso
de medidas disciplinares.
Gerenciando mudanas
11 O controle de mudanas do escopo consiste em garantir que as mudanas sejam dis-
cutidas e acordadas quanto sua efetiva necessidade de implementao no projeto.

11 O processo de gerenciamento de mudanas ativado atravs das requisies de
mudana, que podem ocorrer de muitas maneiras:
22 Oral ou escrita.
22 Direta ou indireta.
22 Iniciada externa ou internamente.
22 Legalmente imposta ou opcional.
11 O controle das mudanas do escopo deve se integrar aos demais processos de
controle e execuo do projeto e previne o chamado scope creep.
Uma das principais atividades de monitoramento e controle consiste na Gesto de Mudanas.
Gerenciar mudanas em um projeto inclui a preveno de um fenmeno chamado scope
creep (desvios de escopo), avaliar e implementar mudanas e minimizar o efeito das
mudanas no documento de escopo. Um processo de controle de mudanas inclui a identificao, avaliao, notificao e a prpria mudana no escopo, cronograma e oramento. Scope
creep, ou a adio gradual e contnua de novos requisitos, pode diretamente afetar a qualidade, o oramento e o cronograma. O gerente de projetos precisa empregar mtodos para
evitar tais efeitos ao seguir estratgias diferentes de lidar com o oramento e o cronograma.
11 Scope creep (desvios de escopo);
11 Aplicando um processo de controle de mudanas;
11 Atividades para o controle de mudanas;
Scope creep (desvios de escopo)

11 Um problema tpico e significativo encontrado durante muitos projetos de TI o
scope creep.
11 Pode ser definido como a adio gradual e contnua de novos requisitos especificao original de um projeto.
11 Scope creep a razo que provoca a falha de muitos projetos.
11 Algumas causas para que ele acontea:
22 Definies muito gerais ou questes no esclarecidas sobre os entregveis, no
incio do projeto.
22 Um escopo ambguo na declarao de trabalho do projeto.
22 Mudanas nas expectativas dos stakeholders.
11 Avaliando alternativas para mudanas de escopo.
22 Identificao de novas possibilidades de desenvolvimento pelo time tcnico.

101
Um problema tpico e significativo encontrado durante muitos projetos de TI o scope creep.

Scope Creep o termo ingls para o efeito da mudana lenta e gradual do escopo de um
projeto, alm dos objetivos planejados inicialmente. medida que a lista de requisitos aumenta,
a complexidade do projeto aumenta ainda mais. Amudana gradual no escopodo projeto ao
longo de seu ciclo de vida pode trazer diversos desafios para o gerente de projetos.Apesar de
a mudana de escopo ser comum (por isso existem processos de gerenciamento de escopo), a
mudana incremental traz riscos adicionais, j que se pode dar menor ateno aos pequenos
impactos no custo e prazo, mas que cumulativamente tendem a ser bastante considerveis.
O scope creep faz muitos projetos falharem. Algumas causas para que acontea:
11 Definies muito gerais ou questes no respondidas sobre entregveis, no incio
do projeto: quando um projeto comea com umescopo mal definido, a tendncia que ele
seja alterado e aumentado com o tempo ainda maior.O escopo no precisa ser definido
nos mnimos detalhes, mas deve ser abrangente o suficiente para deixar claro o que est
includo no projeto (no confundir com adefinio gradual de escopo);
11 Um escopo ambguo na declarao de trabalho do projeto: quando nossa empresa
no tem uma boa disciplina sobre o que foi contratado pelo cliente, temos a tendncia de
ficar adicionando pequenos pedidos sem considerar adequadamente os impactos no
resultado do projeto.Agradar o cliente sempre o objetivo, mas mudanas devem ser
analisadas e informadas adequadamente;
11 Mudanas nas expectativas dos stakeholders: quando as necessidades das partes
interessadas no projeto se modificam, provocando com isso novas demandas que
impactam o escopo do projeto;
11 Identificao de novas possibilidades de desenvolvimento pelo time tcnico: quando
o planejamento e avaliao preliminar do projeto no so realizados adequadamente,
podemos definir um escopo excessivamente simples em relao complexidade dos
objetivos no projeto. Isso naturalmente far com que o escopo seja incrementado conforme o projeto avana.
Empregando um processo para controle de mudanas
11 Durante a evoluo do projeto, o entendimento de problemas e suas possibilidades
de resoluo tambm evoluem.

11 Essa evoluo muitas vezes traz a necessidade de mudanas no documento de
escopo do projeto.
11 O controle de mudanas normalmente a parte mais fraca de um projeto de TI e, se
no for controlada, pode levar a desperdcio de recursos e atrasos no cronograma.
Seu projeto deve ter um bom gerenciamento de escopo, com processos claros e bem defi-
nidos.O controle do escopo deve comear no primeiro dia do projeto, e ser tratado como
102
algo fundamental para seu sucesso. Durante a evoluo do projeto, o entendimento de

problemas e as possibilidades de resoluo tambm evoluem. Essa evoluo muitas vezes
torna necessrias mudanas no documento de escopo do projeto. O controle de mudanas
normalmente a parte mais fraca de um projeto de TI e, se no for controlada, pode gerar
o desperdcio de recursos e atrasos no cronograma. necessrio, portanto, manter um
processo de comunicao contnuo com os stakeholders. Essa comunicao deve ter dois
objetivos principais:entender as expectativas em relao ao projeto e garantir que o escopo
documentando esteja bastante claro para todos.
11 Gerentes de projeto de sucesso fazem o seguinte:
22 Enfatizam o gerenciamento de mudanas e insistem que elas sejam formalmente

aceitas pelos stakeholders.
22 Utilizam o plano de projeto para refletir o impacto das mudanas.
11 Tm um contrato descrevendo as mudanas, como elas sero processadas e quem
vai pagar por elas.
11 Exemplos de mudanas do projeto incluem (mas no esto limitadas) as seguintes:
22 Escopo.
22 Esforo.
22 Pessoal.
22 Gerncia.
22 Economia.
22 Ambiente.
22 Prioridades.
Quando aumentam as presses internas e externas para a mudana de escopo sem adequao de tempo e custo, o gerente de projetos pode ter dificuldades em administrar a
situao se no tiver um patrocinador que compreenda o efeito dessa situao. Por isso
importante trabalhar desde o primeiro dia junto ao patrocinador para que ele apoie as aes
do gerente. Na maioria dos projetos, h uma tendncia a comear a execuo rapidamente,
mesmo que o planejamento ainda no tenha chegado a um nvel adequado.O gerente de
projeto deve equilibrar essa ansiedade de execuo com a necessidade de preparao e
planejamento, j que so medidas que beneficiaro o gerenciamento do escopo.
Alm disso, no momento de definir mudanas de escopo, as prioridades do projeto devem
estar muito claras.Independentemente de quem toma a deciso, as prioridades orientaro,
por exemplo, se mais importante manter o cronograma, restringir os custos ou atender a
um novo escopo.
Mudanas de escopo acontecem em praticamente todos os projetos. Como gerente de projeto,
sua funo no impedir as mudanas, mas fazer com que elas sejam bem-feitas. Tenha isso
em mente antes de sair com a bandeira ningum mexe nesse projeto. Dessa forma, sempre
11 Enfatizar destacadamente o gerenciamento de mudanas e insistir que elas sejam cui-
dadosamente definidas, acuradamente estimadas em termos de custo e formalmente

aceitas por diferentes stakeholders.
11 Utilizam o plano de projeto para refletir o impacto das mudanas.
11 Tm um contrato descrevendo as mudanas, como elas sero processadas e quem
vai pagar por elas.
Exemplos de mudanas do projeto incluem, mas no esto limitadas s seguintes:
11 Escopo: o cliente redefine os requisitos depois de o projeto ter comeado.
11 Esforo: o esforo necessrio maior ou menor do que foi estimado no plano de
projetos.
11 Pessoal: promoes, contrataes, cortes de pessoal, realocaes, doenas, acidentes etc.
que uma mudana for de fato necessria, os gerentes de projetos precisam:
103
11 Gerncia: uma mudana na estrutura organizacional, propriedade corporativa etc.
11 Economia: repriorizao de recursos devido a fatores financeiros que afetam a

empresa.
11 Ambiente: mudana para uma nova facilidade, problemas com fornecimento de
energia, disponibilidade de dados etc.
11 Prioridades: a gerncia reorganiza prioridades organizacionais.
Atividades para o monitoramento e controle de mudanas

Controle de mudanas inclui as atividades a seguir:
11 Identificao e avaliao de mudanas necessrias.

11 Avaliao de impacto das mudanas no escopo, cronograma e custos.
11 Documentao e implementao de mudanas aceitas.
11 Rejeio e documentao de mudanas no aceitas.
As requisies de mudana podem cair em duas categorias:
11 Mudanas necessrias.
11 Mudanas que no so necessrias, mas que podem ser benficas.
Um sistema de monitoramento e controle de mudanas do escopo define os procedimentos
pelos quais o escopo do projeto pode ser mudado. Inclui manuais, sistemas de monitoramento e nveis de aprovao necessrios para autorizao das mudanas. O sistema de controle de mudanas do escopo deve estar integrado com o controle integrado de mudanas
e, em particular, com sistemas aptos a controlar o escopo do produto. Quando o projeto
feito sob contrato, o sistema de controle de mudanas do escopo deve, tambm, estar em
conformidade com todas as clusulas relevantes do contrato.
Monitoramento e controle de mudanas inclui as atividades a seguir:
11 Identificao e avaliao de mudanas necessrias;
11 Avaliao do impacto das mudanas no escopo, cronograma e custos;
11 Notificao dos diversos interessados das mudanas e do seu impacto;
11 Documentao e implementao de mudanas aceitas;
11 Rejeio de mudanas no aceitas;
11 Documentao de mudanas no aceitas;
11 Replanejamento do escopo, cronograma e cronograma com base nas mudanas.
As requisies de mudana podem cair em duas categorias:
11 Mudanas necessrias;
104
11 Mudanas que no so necessrias, mas que ainda assim podem ser benficas.
11 O gerente de projetos e os stakeholders devem concordar a respeito da necessidade
de cada requisio de mudana.
11 Uma vez que uma mudana tenha sido considerada necessria para o projeto,
deve-se avaliar o seu impacto em termos de:
22 Escopo.
22 Cronograma.
22 Oramento.
Uma mudana do escopo qualquer modificao no escopo combinado do projeto, conforme definido pela EAP aprovada. As mudanas do escopo do projeto, frequentemente,
exigem ajustes no custo, no prazo, na qualidade ou em outros objetivos do projeto. Assim, o
gerente de projetos e os stakeholders devem concordar a respeito da necessidade de cada
requisio de mudana.
Mudanas do escopo so retornos (feedback) ao longo do processo de planejar. Os documentos tcnicos e de planejamento so atualizados conforme necessidade, e as partes
envolvidas so informadas conforme for apropriado. Uma vez que uma mudana tenha sido
considerada necessria para o projeto, deve-se avaliar o seu impacto em termos de:
11 Escopo: como a mudana vai afetar os entregveis?
11 Cronograma: a mudana poderia ser concebida sem alterar o caminho crtico? Como a
data de concluso de cada uma das atividades ser afetada?
11 Oramento: que efeito a mudana produzir nos custos do projeto?
Alm disso, as mudanas e o seu impacto precisam ser comunicados claramente para os
stakeholders apropriados, incluindo o time de projetos.
11 Escopo: as mudanas devem ser comunicadas para todos os stakeholders e precisam ser
documentadas em uma reviso ou em um adendo declarao de trabalho, que pode
ento ser distribuda;
11 Cronograma: a EAP e as atividades devem ser atualizadas para refletir a mudana. Uma
mudana no cronograma que afete o projeto inteiro deve ser comunicada para todos os
stakeholders;
11 Oramento: o oramento precisa ser atualizado para refletir a mudana. Mudanas nos
custos devem ser reportadas gerncia executiva, ao cliente e a outros stakeholders.
Avaliando alternativas para evitar mudanas de escopo

Analise de maneira detalhada a natureza da mudana do escopo e o impacto que ela
tem nos objetivos principais do projeto. A mudana no escopo relativa a algum dos
seguintes processos e, se sim, quais?
11 Design, engenharia ou testes.
11 Cdigo de software.
11 Requisitos de rede.
A mudana de escopo parte normalmente do cliente, afinal, so eles que definem o escopo.
O gerente do projeto deve auxiliar no desenvolvimento do termo de abertura e nadefinio
e gerenciamento do escopo. Diante do exposto, primeiramente, o entusiasmo deve partir do
cliente. Juntamente com seu setor, o cliente precisa acreditar na relevncia do projeto, em
seu lado inovador e em sua importncia para os negcios da empresa. Portanto, o gerente
do projeto precisa identificar o perfil do cliente: possui tempo disponvel? do tipo formal?
Qual comunicao deve ser utilizada? Qual a sua expectativa? Como ele costuma controlar
os projetos? E com essas respostas guiar a melhor maneira de extrair do cliente as informaes tcnicas, emocionais, positivas, negativas e criativas. O gerente do projeto no deve
apenas pensar no lado tcnico do produto, mas tambm no perfil do cliente.
Aps definir como gerenciar o projeto, definio que idealmente ser acordada com o
cliente, podemos ou noalteraro escopo do projeto, seguindo os passos definidos no incio.
105
Afinal, a inteno a mesma: entregar o produto funcional, com qualidade, atendendo as

expectativas do cliente.
Assim, como gerente do projeto, analise de maneira detalhada a natureza da mudana do
escopo e o impacto que ela tem nos objetivos principais do projeto. A mudana no escopo
relativa a algum dos seguintes processos e, se sim, a quais?
11 Design;
11 Engenharia;
11 Testes;
11 Cdigo de software;
11 Requisitos de rede;
Uma vez identificados os processos, ou os campos especficos que sero afetados pelas
mudanas, redefina ou alterne esses processos e mtodos para evitar mudanas no documento de escopo.
Evitando scope creep (desvios de escopo)

11 As principais reas do projeto que podem ser afetadas por mudanas de escopo
devem ser avaliadas da seguinte forma:

22 Custos.
22 Adio de recursos.
22 Rearranjo de atividades.
22 Contratao de terceiros.
22 Qualidade.
11 Examine alternativas como:
22 Modificar o processo de trabalho.
22 Disponibilizar mais recursos para atividades de teste.
22 Modificar o projeto.
22 Usar materiais de substituio.
22 Cronograma.
11 Examine alternativas como:
22 Atualizar o cronograma.
22 Alterar o padro de recursos tcnicos.
22 Usar ferramentas diferentes.
106
As principais reas do projeto que podem ser afetadas por mudanas de escopo devem ser
avaliadas da seguinte forma:
Custos
Que aes podem ser tomadas para acomodar a mudana de escopo sem aumentar os
custos? Examine alternativas tais como adio de recursos, rearranjo de atividades e terceirizao de atividades para fornecedores conhecidos.
Qualidade
Que aes podem ser tomadas para acomodar a mudana de escopo e minimizar o impacto
na qualidade? Examine alternativas como a modificao do processo de trabalho, a disponibilizao de mais recursos para atividades de teste e o uso de materiais de substituio para
a composio do produto. O gerenciamento da qualidade pode provocar a modificao do
projeto como um todo.
Cronograma
Que aes podem ser tomadas para acomodar a mudana de escopo sem colocar em risco
o cronograma? Examine alternativas tais como atualizao de cronograma, alterao de
padro de recursos tcnicos e utilizao de ferramentas mais poderosas de gerenciamento
de projetos.
107
108
6
Reconhecer a importncia do encerramento do projeto. Identificar o propsito de uma
reunio de aceitao com o cliente. Identificar o propsito de uma reunio de reviso
do projeto. Identificar as lies aprendidas. Descrever um relatrio de projeto
conceitos
Encerramento formal. Lies aprendidas
1. Por questo de tempo, podemos ignorar a parte de encerramento de um projeto.
(a) Verdadeiro
(b) Falso
2. Como a parte de encerramento pode ser til no planejamento de projetos futuros?
3. A aceitao do cliente no faz parte da fase de encerramento.

(a) Verdadeiro
(b) Falso
Introduo
11 A fase de encerramento necessria em qualquer projeto, e no deve ser evitada por
restries de tempo.
11 Essa fase ser precedida por uma discusso acerca da necessidade de uma reunio
de reviso do projeto e da identificao das lies aprendidas.
q
Captulo 6 - Encerramento
objetivos
Encerramento
109
Esta sesso introduz a ltima das fases de um projeto de TI. O encerramento inclui os
processos usados para finalizar formalmente todas as atividades de um projeto (ou de uma
fase deste), entregar o produto terminado ou encerrar um projeto cancelado. A fase de
encerramento uma parte necessria de qualquer projeto, e no deve ser descartada por
restries de tempo.
Nesta sesso, o aluno ser apresentado ao propsito e importncia de se conduzir uma
Planejamento
reunio para aceitao
do projeto pelo cliente. O grupo de processos que compe o encerramento serve para verificar se os processos estabelecidos foram finalizados, servindo ao
estabelecimento formal do trmino do projeto ou de fase.
Denio de
Essa fase ser precedida de uma discussoExecuo
sobre a necessidade de reviso do projeto e
Escopo
da identificao das lies aprendidas. Os problemas enfrentados ao longo do projeto so
uma ferramenta til para mudar os processos de negcio atuais e podem servir tambm a
projetos futuros. Nessa
ltima sesso, tambm ser enfatizada a necessidade de elaborao
Encerramento
de um relatrio de projeto.
1. Iniciao
2. Planejamento
3. Execuo
5. Enceramento
Figura 6.1
As fases de um
projeto.
Encerramento do projeto
11 Um encerramento de projeto bem planejado pode ser to importante quanto o
plano de projetos, em termos de manuteno de clientes e construo da confiana

dos stakeholders.
11 O encerramento do projeto deve enderear as necessidades de todos os stakeholders
que estiveram no projeto desde o seu incio.
11 Depois que o projeto estiver concludo, importante:
22 Reconhecer o trabalho que o time de projetos realizou e prover um senso de finalizao.
22 Revisar as lies que foram aprendidas durante o projeto.
Todo projeto (ou fase de projeto) requer um encerramento formal, aps alcanar seus objetivos
ou vir a terminar por outras razes. O encerramento consiste em documentar os resultados do
projeto para formalizar a aceitao do produto do projeto pelos patrocinadores ou clientes.
O encerramento do projeto inclui:
110
11 A coleta dos registros do projeto, garantindo que reflitam as especificaes finais;

11 Anlise do sucesso, da efetividade do projeto e das lies aprendidas, alm do arquivamento
dessas informaes para uso futuro.
Um encerramento de projeto bem planejado pode ser to importante quanto o plano de
projetos, em termos de manuteno de clientes e construo da confiana dos stakeholders.
As atividades do encerramento no devem ser retardadas at a concluso do projeto. Cada

fase do projeto deve ser apropriadamente encerrada para assegurar que as informaes
teis e importantes no sero perdidas. Em adio, as habilidades dos funcionrios da organizao devem ser atualizadas no banco de dados para refletir novas habilidades e aumento
da proficincia.
O encerramento do projeto deve enderear as necessidades de todos os stakeholders que
estiveram no projeto desde o seu incio. Toda a documentao produzida para registro e
anlise do desempenho do projeto, incluindo os documentos de planejamento que estabeleceram a estrutura da medio do desempenho, deve estar disponvel para revises
durante o encerramento administrativo. Os envolvidos no projeto podem ter um conjunto
de necessidades completamente diferente na concluso do projeto, em relao ao que havia
durante o desenvolvimento. Se o gerente de projeto se prepara para tais necessidades, o
encerramento pode se tornar uma oportunidade importante para todos os envolvidos.
Aps a concluso do projeto, importante fazer o seguinte:
11 Reconhecer o trabalho que o time de projetos realizou, provendo um senso de finalizao;
11 Revisar as lies aprendidas durante o projeto.
H ainda atividades que precisam ser realizadas aps o fim do projeto:
11 Reunio com os clientes para garantir a aprovao final dos entregveis.

11 Realizar uma reviso do projeto.
11 Preparar um relatrio do projeto.
11 Finalizar a contabilidade do projeto.
11 Liberar os recursos do projeto.
11 Coletar arquivos do projeto e armazen-los para acesso posterior.
Algumas atividades precisam ainda ser realizadas depois do projeto chegar ao fim. Um conjunto completo dos registros indexados do projeto deve ser preparado para arquivamento
pelas partes apropriadas, incluindo o seguinte:
11 Reunio com os clientes para garantir a aprovao final dos entregveis;
11 Realizar uma reviso de projetos;
11 Preparar um relatrio do projeto;
11 Finalizar a contabilidade do projeto;
11 Liberar os recursos do projeto;
11 Coletar arquivos do projeto e armazen-los para acesso futuro;
11 Atualizar os bancos de dados pertinentes ao projeto.
taes, deve ser dispensada ateno particular ao arquivamento dos registros financeiros.
Quando os projetos so feitos sob contrato ou envolvem um volume significativo de contra-
111
Realizando uma reunio de aceitao com o cliente

11 Um dos objetivos do gerenciamento de projetos obter aceitao do cliente em
relao ao resultado do projeto.

11 A reunio de aceitao com o cliente inicia a fase de encerramento do projeto.
11 Seus propsitos so:
22 Verificar que os critrios de aceitao do projeto foram satisfeitos.
22 Obter a aceitao formal do cliente.
Um dos objetivos do gerenciamento de projetos obter aceitao do cliente em relao
ao resultado do projeto. Idealmente, o gerente do projeto obter a confirmao de que
o projeto atendeu a todos os requerimentos de produto: o cliente aceitou formalmente
os resultados e entregas do projeto e os requerimentos solicitados pela organizao; por
exemplo, evolues do staff, relatrios oramentrios, lies aprendidas etc. A concluso
do projeto torna perceptvel padres e objetivos mensurveis que resolvem determinados
problemas do cliente.
A reunio de aceitao com o cliente inicia a fase de encerramento do projeto, com o intuito
de verificar que os critrios de aceitao do projeto foram satisfeitos e obter a aceitao
formal do cliente.
Se o cliente no concordar que os critrios de aceitao foram satisfeitos, deve estabe-
lecer com o gerente de projeto, atravs de acordo formal e escrito, os prximos passos.
11 Aceitao do projeto com desvios ou omisses, anotadas e explicadas.
11 Aceitao do projeto com compensaes monetrias ou de outra ordem para o
cliente, ou para o patrocinador do projeto, por causa dos desvios ou omisses.
11 Continuao do projeto at que todos os critrios de aceitao e sucesso
sejam satisfeitos.
Todas as atividades e interaes para resolver e encerrar contratos estabelecidos para o
projeto precisam ser definidas na reunio de aceitao com o cliente. Tambm nela haver
a definio das atividades relacionadas que do suporte ao encerramento administrativo
formal do projeto.Se o cliente no estiver certo que os critrios de aceitao foram satisfeitos, ento o gerente de projeto e o cliente devem chegar a um acordo, formal e escrito,
acerca dos prximos passos. Isso pode incluir o seguinte:
11 Aceitao do projeto com desvios ou omisses, anotadas e explicadas;
11 Aceitao do projeto com compensaes monetrias ou de outra ordem para o cliente,
ou para o patrocinador do projeto, por causa dos desvios ou omisses;
11 Continuao do projeto at que todos os critrios de aceitao e sucesso sejam satisfeitos.
112
Os termos e condies do contrato podem tambm definir especificaes para o encerramento do contrato que precisam ser parte desse procedimento. A resciso de um contrato
um caso especial de encerramento do contrato que pode envolver:
11 A incapacidade de entregar um produto;
11 Um estouro do oramento;
11 Falta de recursos.
O resultado da reunio de aceitao com o cliente deve estar presente no relatrio final
do projeto. Esse procedimento desenvolvido para fornecer uma metodologia passo a
passo que aborda os termos e condies dos contratos e quaisquer critrios de sada ou
de trmino necessrios para o encerramento do contrato. Ele contm todas as atividades e
responsabilidades relacionadas dos membros da equipe do projeto, clientes e outras partes
interessadas envolvidas no processo de encerramento dos contratos. As aes realizadas
encerram formalmente todos os contratos associados ao projeto terminado.
Quando necessrio, podemos envolver recursos que sirvam de opinio especializada para o
encerramento do projeto, processo aplicado no desenvolvimento e realizao dos procedimentos de encerramento administrativo e de encerramento de contratos.
A aceitao do cliente um dos principais objetivos do gerenciamento de projetos.
Conduzindo uma reviso de projeto

11 Uma reunio de reviso de projeto deve ser conduzida logo aps a reunio de acei-
tao com o cliente.

11 O propsito dessa reviso identificar as lies aprendidas e obter o encerramento
do projeto.
11 Essa reunio precisa ter objetivos definidos e questes que devem ser endereadas
durante a reunio.
A reviso do projeto deve ser conduzida em formato de reunio, embora os participantes
possam preparar algumas revises somente com seus times locais. Quando implementadas
pelas equipes, as revises tambm se constituem em oportunidades para a descoberta
de designs e cdigos de outros grupos, aumentando assim as possibilidades de detectar
cdigo-fonte comum, oportunidades de reutilizao e de generalizao. As revises so uma
maneira de coordenar entre os vrios grupos o estilo de arquitetura em desenvolvimento.
Uma reunio de reviso de projeto deve ser conduzida logo aps a reunio de aceitao
com o cliente. O propsito dessa reviso identificar as lies aprendidas e obter o encerramento do projeto.
11 Uma reunio de reviso de projeto deve englobar os seguintes pontos:
22 Incluir todos os aspectos do planejamento do projeto, organizao, execuo do

plano, gerenciamento e finanas.
22 Identificao dos aspectos do projeto que foram bem-sucedidos e dos que precisam de melhorias.
22 Identificao de possveis melhorias para os processos existentes.
deve estar presente.

11 A reunio deve ser precedida por um questionrio que ajuda os membros do time a
se concentrarem nos objetivos da reunio.
11 Para projetos muito grandes, pelo menos um representante de cada rea principal
113
Em gerenciamento de projetos, as revises desempenham um papel importante, embora

secundrio, na garantia da qualidade. Assim, podemos identificar um efeito adicional importante que as revises exercem no desenvolvimento profissional: equipes de iniciantes tm a
oportunidade de ver o trabalho de especialistas e tm o seu prprio trabalho revisado por
profissionais mais experientes.
Uma reunio de reviso do projeto um ponto crtico para o encerramento do projeto.
Essa reunio precisa ter objetivos definidos e questes que devem ser endereadas durante
sua realizao. Uma reunio de reviso de projeto deve englobar os seguintes pontos:
11 Incluir todos os aspectos do planejamento do projeto, organizao, execuo do plano,
gerenciamento e finanas;
11 Identificar que aspectos do projeto foram bem-sucedidos e quais precisam de melhorias;
11 Identificar possveis melhorias para processos existentes;
11 Conduzir a reunio o mais prximo do final do projeto possvel;
Importante ressaltar que todos os membros do projeto precisam estar presentes. Em projetos
muito grandes, pelo menos um representante de cada rea principal deve estar presente.
A reunio deve ser precedida pela aplicao de um questionrio que ajuda os membros do
time a se concentrarem nos objetivos da reunio.
Podemos citar os seguintes objetivos tpicos:
11 Aprendizagem geral com a experincia.

11 Como repetir os pontos bem-sucedidos.
11 Como os eventos menos bem-sucedidos podem ser tratados de maneira diferente no
futuro.
11 Disponibilizar dados que possam beneficiar outras pessoas.
A reviso do projeto precisa criar um documento que sirva para controle na reviso de artefatos do projeto. Esse documento deve ser elaborado para que os participantes iniciem o
processo de reviso, sendo usado para capturar os resultados e os itens de ao resultantes
da reunio de reviso. Ele constitui um registro da reviso e de suas concluses, que pode
ser posteriormente submetido auditoria.
Podemos citar os seguintes objetivos tpicos da reunio de reviso do projeto:
11 Aprendizagem geral com a experincia;
11 Repetir pontos bem-sucedidos;
11 Tratar eventos menos bem-sucedidos de uma maneira diferente no futuro;
11 Disponibilizar dados que podem beneficiar outras pessoas;
114
11 Identificar processos que precisam ser mudados.
Para que a reunio de reviso do projeto funcione de forma eficiente, necessrio que
todos compreendam que o objetivo dela melhorar a qualidade dos projetos realizados por
uma organizao. Os artefatos devero ser revisados com um olhar crtico na deteco de
problemas. Como poder ser uma tarefa difcil, todos os participantes no podem perder de
vista que devem concentrar-se na identificao de problemas. A tendncia natural de partir
para a resoluo os problemas dever ficar de lado nessa reunio.
O gerente do projeto e o time do projeto devero estudar a documentao, elaborando
perguntas e identificando problemas a serem discutidos,antes da reviso. Devido carga de
trabalho normal dos participantes da reviso de projeto, o tempo mnimo necessrio de preparao para a reunio de reviso geralmente de alguns dias de trabalho. O documento
de reviso do projeto um artefato usado para capturar os resultados de uma reviso de
projeto todos os projetos devem utiliz-lo. Seu nvel de formalidade depender do grau
de formalidade dos relacionamentos entre cliente e desenvolvedor ou do grau de formalidade da prpria organizao do desenvolvedor, no que diz respeito ao cumprimento do
processo. Por exemplo, o contrato pode declarar que os registros de reviso sero submetidos a processo de auditoria.
Encerramento do projeto
Durante esse exerccio, o aluno vai detalhar a contribuio do encerramento do projeto para
o seu sucesso. Ele dever descrever o papel de um cliente bem informado em um encerramento bem-sucedido de projeto.
1. Como um bom encerramento de projeto pode contribuir para o seu sucesso?
2. Como um cliente bem informado normalmente encara o encerramento bem-sucedido de
um projeto?
115
3. Liste ao menos cinco atividades que ocorrem durante a fase de encerramento de um

projeto de TI.
Tabela 6.1
rea do projeto
Questes
Definio do escopo e
construo do time
O papel do gerente de projetos foi bem definido?
Planejamento
O planejamento foi realizado adequadamente?
O time de projeto possua os membros corretos? Foram necessrios outros membros?
O plano foi acompanhado adequadamente?
Custos
Os custos foram antecipados adequadamente?
Recursos
Os recursos estavam disponveis quando foram necessrios?
As ferramentas utilizadas no projeto eram adequadas?
116
Comunicao
e reunies
As comunicaes ocorreram adequadamente e no momento certo?
Reflexes
O que mais lhe agradou durante o projeto?
As reunies foram teis e necessrias?
O que voc acha que foi frustrante durante o projeto?
4. Liste dois propsitos de uma reunio de reviso de projeto.
5. Qual o ltimo passo da fase de encerramento?
Identificando as lies aprendidas

11 Empresas que dedicam tempo a aprender com seus projetos, sejam esses bem-suce-
didos ou no, obtm resultados bem melhores e consistentes em projetos futuros.
O banco de dados
tambm a base para a
gerncia do conhecimento.
11 Mantenha uma lista dos processos e mudanas realizados durante a vida do projeto.
As causas das varincias, as razes para as aes corretivas tomadas e outros tipos de
aprendizado prtico devem ser documentadas em um banco de dados, no s para o
projeto em andamento, mas para os demais projetos da organizao executora.
Empresas que dedicam tempo ao aprendizado com seus projetos (sejam eles bem-sucedidos
ou no) obtm resultados melhores e mais consistentes em projetos futuros. Patrocinadores
deveriam insistir em revises regulares de lies aprendidas, durante o projeto e aps a sua
implementao. uma boa forma de capturar novas ideias e outras formas de trabalho que
podero ser teis no futuro. Portanto, mantenha uma lista dos processos e mudanas realizados durante a vida do projeto.
Lies aprendidas:
11 Devem ser armazenadas durante a vida de um projeto.

11 Devem ser revisadas no fim de cada fase principal.
11 Devem ser identificadas e analisadas em detalhe.
11 So dinmicas e englobam processos e pessoas.
A teoria diz que documentar lies aprendidas uma atividade importantssima durante um
projeto. Qualquer gerente de projeto concordar com isso, mas nem sempre essa atividade
executada com a seriedade necessria. Muitas vezes, as lies aprendidas so deixadas de
lado, por fatores como:
11 Presso para cumprir prazos, levando o gerente a se preocupar mais com as atividades
diretamente relacionadas ao produto do projeto;
11 Falta de interesse da alta gesto nesse tipo de documento;
11 Fatores de cultura organizacional, como a mudana de foco ao terminar um projeto, j que
natural se concentrar mais no prximo projeto do que no fechamento do projeto atual.
117
De maneira a identificar as lies aprendidas, o gerente de projetos deve responder
perguntas como:
11 O que mais lhe agradou durante o projeto?
11 O que foi frustrante durante o projeto?
11 O que foi bem-sucedido?
11 O que foi malsucedido?
11 O que no foi conquistado que deveria ter sido?
11 O que voc faria diferente?
O relatrio final do projeto deve responder a uma srie de perguntas combinadas, que
podem ser explicitamente includas no texto, se for o caso. Por causa de questes como
essas, o gerente de projeto deve entender que as lies aprendidas so uma ferramenta
essencial para seu crescimento profissional e para a melhoria contnua da sua organizao. Representam muito mais do que um documento para cumprir a formalidade do
projeto. So as informaes que permitiro que os erros no se repitam e os acertos
possam ser alcanados novamente. Por isso importante registrar tanto as boas quanto
as ms experincias do projeto. Esses registros ajudaro a moldar as atividades e controles dos futuros projetos.
De maneira a identificar claramente as lies aprendidas, o gerente de projetos necessita
responder a perguntas como as seguintes:
11 O que mais lhe agradou durante o projeto?
11 O que voc acha que foi frustrante durante o projeto?
11 O que foi bem-sucedido?
11 O que foi malsucedido?
11 O que no foi conquistado que deveria ter sido?
11 O que voc faria diferente?
Compilando um relatrio de projeto

11 Quando a reunio do projeto estiver encerrada, as informaes pertinentes devem
ser resumidas em um relatrio de projeto.

11 O relatrio final a histria do projeto inteiro.
Os resultados de um projeto e todas as informaes e experincias obtidas durante a sua
execuo precisam ser documentados no relatrio final do projeto. Quando a reunio do
projeto estiver encerrada, as informaes pertinentes devem ser resumidas em um relatrio
de projeto. O relatrio final a histria do projeto inteiro e serve como o ltimo elemento na
118
cadeia de relatrios de um projeto. uma prestao de contas da vida do projeto: o que foi
bem e o que deu errado, quem trabalhou no projeto e em que capacidade, e como o projeto
foi gerenciado.
O relatrio de projeto precisa incluir o seguinte:
11 Uma breve descrio do projeto.
11 Uma medida do sucesso.
11 As lies aprendidas.
11 Explicaes para variaes no cronograma e/ou custos
importante ter o entendimento de que o relatrio de projeto servir como um recurso

para outros projetos. Alm disso, os componentes bsicos do projeto devem ser divulgados
na organizao (atravs de newsletters, memorandos, e-mails etc.). O relatrio de projeto
precisa incluir:
11 Uma breve descrio do projeto: um pequeno resumo do projeto, seus objetivos, o que
se esperava atingir e uma bsica descrio dos principais resultados obtidos;
11 Uma medida do sucesso: apresente os resultados do projeto. Nesse ponto, recomendvel incluir resultados quantitavos e qualitativos. Tabelas, grficos e outras figuras que
representem os dados do projeto so timas formas de resumir o projeto e apresent-lo
de forma acessvel;
11 Explicaes para variaes no cronograma ou custos: detalhe os planos iniciais e
como eles foram obtidos, e explique as mudanas no projeto que causaram os desvios na
linha de base;
11 As lies aprendidas: informaes extremamente valiosas para a organizao, e para
outros que viro a estudar o tpico no futuro, alm de ser um documento fundamental
para avaliao do projeto.
11 Assim como analisa o projeto atual, o relatrio pode conter recomendaes para
projetos futuros, baseadas nas lies aprendidas.

11 O objetivo principal do relatrio final melhorar projetos futuros.
O relatrio do projeto cobre todo o projeto, com todas as atividades realizadas e a durao
aprovada para o projeto (do incio at o fim do projeto). Assim como analisa o projeto atual, o
relatrio pode conter recomendaes para projetos futuros, baseadas nas lies aprendidas.
extremamente recomendvel que todos os stakeholders do projeto sejam envolvidos em
algum momento da preparao do relatrio. O objetivo principal do relatrio final melhorar
projetos futuros, atravs da disponibilizao de informaes sobre os projetos encerrados em
uma organizao, com o fornecimento de uma base para o acompanhamento financeiro e do
progresso de projetos pertencentes a um mesmo programa.
119
120
Rodrigo Alves Costa atualmente

professor efetivo do curso de Cincias
da Computao da Universidade Estadual da Paraba e doutorando em Cincias da Computao na Universidade
Federal de Pernambuco (UFPE). Possui
mestrado em Cincias da Computao
pela UFPE (2010), MBA em Gerenciamento de Projetos pela
Fundao Getlio Vargas (2007) e graduao em Cincias da
Computao pela UFPE (2005). certificado Project Management Professional (PMP) pelo Project Management Institute
(PMI) (2006). Tem vasta atuao profissional, destacando-se
em funes como executivo de projetos, analista de sistemas, engenheiro de sistemas, de segurana e de software
em empresas como IBM, Siemens, Motorola e C.E.S.A.R.
Tambm autor de livros na rea de administrao organizacional com foco em projetos, entre os quais Gerenciamento de Projetos de TI, e colaborador de cursos de gesto
empresarial em tecnologias da informao e comunicao
em diversas organizaes e instituies de ensino, sendo
um dos idealizadores do currculo de governana da Rede
Nacional de Pesquisa, vinculado ESR/RNP/CNPQ. Foi bolsista CNPQ durante o mestrado e a graduao (PIBIC), e atualmente est vinculado aos diretrios de pesquisa da
entidade, no grupo de estudos em Segurana Computacional da UFPE. Pesquisador na rea de Cincia da Computao, com nfase em segurana computacional e teoria da
computao, e na rea de Gerenciamento de Projetos, com
nfase em gerenciamento de projetos virtuais e planejamento estratgico orientado por TIC. membro entusiasta
do PMI, membro da Association for Computing Machinery
(ACM) e da Sociedade Brasileira de Computao (SBC).
LIVRO DE APOIO AO CURSO
O curso capacita na utilizao da tecnologia e das ferramentas necessrias para o planejamento, gesto e controle de projetos de TI, atendendo aos requisitos de uma
formao slida e consistente, contemplada no conjunto
de boas prticas contido no Project Management Body
of Knowledge (PMBok) do Project Management Institute
(PMI). Prepara o aluno na elaborao de um diagnstico
dos objetivos organizacionais, considerando o alinhamento s necessidades de TI de sua organizao; a gerir
um portflio de projetos de TI inseridos no planejamento
estratgico organizacional, em todas as reas de conhecimento do PMBok.
02 5
630025

Gerenciamento de Projetos de TI

Uploaded by

Document Information

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Gerenciamento de Projetos de TI

Uploaded by

Copyright:

Gerenciamento

A RNP Rede Nacional de Ensino

Programa Interministerial RNP,

Copyright 2016 Rede Nacional de Ensino e Pesquisa RNP

Jos Luiz Ribeiro Filho

Escola Superior de Redes

Leandro Marcos Oliveira Guimares

Edson Kowask Bezerra

Equipe ESR (em ordem alfabtica)

Checklist de um projeto arruinado12

4. Plano de gerenciamento do projeto

5. Execuo, monitoramento e controle

Escola Superior de Redes

As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das

Convenes utilizadas neste livro

Projetos. Gerenciamento de Projetos. Gerenciamento Efetivo de Projetos. Sucesso ou

11 Muitas empresas tm investido em mltiplos projetos de Tecnologia da Informao (TI).

11 Gerentes de projeto possuem a responsabilidade de gerenciar e trabalhar pelo

sucesso ou falha com papel crtico em um projeto.

Para tanto, de maneira geral, os tpicos a seguir sero discutidos:

gerentes de projeto de TI usam diferentes tcnicas de gesto.

11 A maioria das empresas de TI possui mltiplos projetos que acontecem simultaneamente,

11 Gerenciamento de projetos de TI envolve a necessidade de suporte repetitivo e projetos

Empresas com um desempenho aceitvel

Projetos com baixa qualidade nestas trs reas

profundidade necessria para melhorar as chances de sucesso do projeto. Dentro dessa

11 H muitos caminhos para atingir o objetivo final.

Quando as empresas eliminam a baixa

diferentes formas, dependendo de seus processos, procedimentos e cultura organizacional.

11 Ferramentas permitem planejar e acompanhar o progresso do projeto:

The International Journal of Project Management

Project Management Journal (PMJ)

de livre discusso de problemas relacionados ao gerenciamento de projetos, solues, apli-

caes e opinies. O PMJ publicado em maro, junho, setembro e dezembro.

Introduo ao Gerenciamento de Projetos de TI

2. Quem o gerente de projeto?

3. Cite um software conhecido para gerenciamento de projetos.

4. Qual a diferena entre gerenciamento de projetos de TI e de outros tipos de projeto?

5. Cite dois fatores que podem tornar um projeto bem-sucedido.

11 Limites de custos (por exemplo, um oramento);

particularidades a mais, que demandam do gerente de projetos uma habilidade ainda

Diferena entre projetos e processos

11 Projetos se caracterizam por serem nicos e temporrios.

O que gerenciamento de projetos?

11 Compra de insumos e materiais;

Observa a execuo do projeto para identificar possveis problemas e habilita a tomada de

Inquirir, revisar tempo e performance de custos, comemorar, compilar lies aprendidas e

Estgios do ciclo de gerenciamento de projetos

11 Observar o problema com clareza.

11 Restringir o escopo do projeto.

11 Associar atividades a marcos de performance, e marcos de performance a

Estgio de planejamento e escopo

22 Garantir suporte da alta-gerncia.

22 Negociar e gerenciar mudanas.

Por que o gerenciamento de projetos necessrio?

11 Dois fatores tm influenciado essa performance to fraca:

Checklist de um projeto arruinado

Principais fatores para o sucesso de um projeto

Exemplo de custo da falha

Stakeholders. Justificativa de Projeto. Escopo e Requisitos. Papis e responsabilidades

2.1.Quem cria um termo de abertura de projeto?

3. O mapeamento de riscos no faz parte de um documento de escopo:

11 Definir e documentar o escopo o primeiro passo do gerenciamento de projetos.

11 Definir o escopo significa identificar claramente um problema, os objetivos e metas

11 Anlise de custo e benefcio;

Determinar o escopo identificar com clareza os objetivos e metas do projeto, e o

Identificando expectativas e necessidades dos stakeholders