Você está na página 1de 62

MINISTRIO DA EDUCAO

UNIVERSIDADE FEDERAL RURAL DA AMAZNIA


PLANO NACIONAL DE FORMAO DE PROFESSORES DO ESTADO DO PAR-PARFOR-PA


CURSO DE LICENCIATURA EM COMPUTAO

Gerenciamento de Projetos de TI
Professor: Cleyson Andersson
E-mail: cleysonandersson@gmail.com







Benevides- PA
2014

Sumrio


Gerenciamento de Projetos de TI


Unidade I
1 HISTRIA DA GERNCIA DE PROJETO........................................................................................................2
1.1 Projeto............................................................................................................................. .............................3
1.2 Gerenciamento de projeto.................................................................................................................. .5
1.3 O gerente de projeto ..............................................................................................................................7
1.4 Ciclo de vida de um projeto ............................................................................................................... .9
1.4.1 Conceber .......................................................................................................................................................9
1.4.2 Denir...........................................................................................................................................................11
1.4.3 Iniciar ........................................................................................................................................................... 12
1.4.4 Executar ...................................................................................................................................................... 12
1.4.5 Fechar .......................................................................................................................................................... 13
1.5 Passos fundamentais para a gerncia de projeto ................................................................... 13
1.5.1 Metodologia.............................................................................................................................................. 13
1.5.2 Comunicao............................................................................................................................................ 14
1.5.3 Escopo e atividades................................................................................................................................ 14
1.5.4 Recursos envolvidos no projeto ........................................................................................................ 15
1.5.5 Desenvolvimento do cronograma.................................................................................................... 16
1.5.6 Riscos ........................................................................................................................................................... 16
1.5.7 Incio e m do projeto .......................................................................................................................... 17
1.6 Mnimo necessrio para o gerenciamento de projetos ........................................................ 17



Unidade II
2 MICROSOFT PROJECT............................................................................................................................. ........ 24
2.1 Apresentao do Microsoft Project .............................................................................................. 25
2.2 Criando um novo documento de projeto................................................................................... 26
3.3 Como criar um cronograma no Project? .................................................................................... 28
3.4 Acompanhando o progresso das atividades.............................................................................. 32
3.5 Controlando os custos das atividades e projeto...................................................................... 33
3.6 Gerando relatrios sobre o projeto ............................................................................................... 35
3.7 Formas de exibio .............................................................................................................................. 35
GERENCIAMENTO DE PROJETOS DE TI


3.8 Calendrio ............................................................................................................................. .................. 36
3.9 Grco de Gantt ............................................................................................................................. ...... 36
3.10 Diagrama de rede............................................................................................................................... 37
3.11 Grco de recursos ............................................................................................................................ 37
3.12 Planilha de recursos.......................................................................................................................... 38



Unidade III
3 GESTO DOS RISCOS EM TI......................................................................................................................... 39
4.1 O caso Titanic......................................................................................................................................... 40
4.2 O processo de gerenciamento de riscos...................................................................................... 42
4.3 Avaliao dos riscos ............................................................................................................................ 44
4.4 Identicao dos riscos ..................................................................................................................... 45
4.5 Quanticao dos riscos ................................................................................................................... 46
4.6 Priorizao ............................................................................................................................. ................. 48
4.7 Ficha de controle de risco ................................................................................................................. 50
4.8 Anlise de riscos quantitativos ....................................................................................................... 52
4.9 Avaliao do plano de projeto ........................................................................................................ 55
4.10 Tomada de deciso ............................................................................................................................ 56
4.11 Mtodo do valor esperado ............................................................................................................. 57
4.12 Software de controle de risco ...................................................................................................... 58

Unidade IV
4 GESTO DA QUALIDADE EM TI .................................................................................................................. 59
5.1 Controle da qualidade ........................................................................................................................ 59
5.1.1 NBR ISO 9001: Sistema de Gesto da Qualidade ...................................................................... 60
5.1.2 NBR ISO 10006: Gesto da Qualidade Diretrizes para a qualidade
no gerenciamento de projetos ..................................................................................................................... 64
5.1.3 Maturidade em desenvolvimento de software CMMI ......................................................... 65
5.1.4 Governana em TI................................................................................................................................... 67
5.1.5 CobiT ............................................................................................................................................................ 68
6 CONCLUSO ...................................................................................................................................................... 81
7 REFERENCIAS.............................................................................................................................................. 81

VIII. Anexo .............................................................................................................................
VIII I Slides sobre Conceitos bsicos I ....................................................................
VIII II Slides sobre Conceitos bsicos II .................................................................


GERENCIAMENTO DE PROJETOS DE TI

Unidade I


INTRODUO

De acordo com o Dicionrio Michaelis da Lngua Portuguesa,
projeto (do latim projectu) um plano para a realizao de um
ato. Desta forma, um projeto um esforo temporrio para
5 criar um produto, servio ou mesmo um resultado. A prpria
natureza temporria do projeto, indica que possui um comeo e
um m. Assim, sabemos que o m do projeto atingido quando
chegamos ao objetivo nal.

Projetos tm acontecido desde os tempos mais antigos, como
10 exemplo pode-se citar a pintura Mona Lisa (Vinci) de Leonardo
da Vinci.

Alguns exemplos de projeto so:

implementao de um sistema de TI (Ex: ERP, CRM, etc.);

construo de um edifcio;

15 desenvolvimento de um novo produto (televisor,
automvel, etc.).

Podemos entender que Gerenciamento de Projeto a
aplicao de conhecimentos, habilidades, ferramentas e tcnicas
para a elaborao das atividades para atingir os requerimentos
20 do projeto.

Por que apenas agorao gerenciamento de projeto tem
ganhado um foco especial? Basicamente porque a audincia
mudou. No passado, o gerenciamento de projetos era realizado









1
Unidade I


apenas por pessoas que direcionavam suas carreiras para o
planejamento e gerenciamento. Nos dias atuais, o gerenciamento
de projetos tornou-se um conhecimento crtico e no apenas
uma opo de carreira.

5 Embora atualmente o gerenciamento de projetos seja um
conhecimento critico, mais e mais pessoas esto direcionando
suas carreiras para esta rea. Para regulamentar e padronizar a
prtica da prosso no mundo, em 1969, na Filadla, EUA, foi
criado o Project Management Institute (PMI), instituio sem
10 ns lucrativos que hoje conta com mais de 500.000 associados
em 185 pases.


O PMI um lder global no desenvolvimento de padres para
o gerenciamento de projetos, assim sua publicao A Guide to
the Project Management Body of Knowledge, mais conhecida
15 como PMBOK, internacionalmente conhecida e aceita como
padro para o gerenciamento de projetos.

Desde 1984, o PMI possui um rigoroso programa de certicao
chamado Project Management Professional, ou PMP, que tem o
objetivo de promover o crescimento da prosso e reconhecer as
20 realizaes e conhecimentos dos indivduos sobre o tema.


1 HISTRIA DA GERNCIA DE PROJETO


A disciplina de gerncia de projeto foi desenvolvida por meio
de diversos campos de aplicao distintos, como Engenharia civil,
eltrica, militar, pois, no incio dos anos 60, as empresas e outras
organizaes comearam a perceber o benefcio de organizar
25 seus trabalhos em projetos.

Os grandes projetos governamentais tornaram-se base para
metodologias de projeto atuais, como a ferrovia transcontinental
dos Estados Unidos da Amrica, que comeou a ser construda
na dcada de 1860. Os lderes se viram diante de uma tarefa
30 assustadora, para no dizer impossvel: organizar o trabalho











2
GERENCIAMENTO DE PROJETOS DE TI


manual de milhares de trabalhadores e o processamento e a
montagem de matria-prima.

Frederick Taylor iniciou seus estudos detalhados do trabalho
prximo virada do sculo, onde aplicou raciocnio cientco,
5 de forma a apresentar que a mo de obra poderia ser analisada e
aperfeioada aplicando o conceito de trabalhar com mais ecincia.

Taylor tinha um scio, chamado Henry Gantt,, que estudou a
ordem das operaes no trabalho, enfatizando a construo de
navios durante a Primeira Guerra Mundial. Os grcos de Gantt
10 so comprovadamente uma ferramenta analtica avanada para
o gerenciamento de projeto e permaneceram praticamente
inalterados por quase cem anos.


1.1 Projeto


Nem todas as atividades que desenvolvemos em nosso dia a
dia so projetos, assim no importa o tamanho de um projeto,
15 tipicamente, ele apresenta os seguintes componentes:

escopo: todo projeto tem a nalidade de produzir um
resultado, seja ele um produto ou um servio;

tempo: projetos no duram eternamente, assim deve
existir um incio e um m;

20 oramento: todo projeto possui um oramento denido
que trata sobre a quantidade de indivduos, equipamentos,
informao e dinheiro disponvel;

recursos: consomem recursos humanos e no humanos;

multifuncionais: atravessam diversas linhas funcionais.


25 Estes componentes podem ser representados pelo tringulo
do projeto, um smbolo popularizado por Harold Kerzner em seu
trabalho, Project Management: A Systems Approach to Planning,
Scheduling, and Controlling (Kerzner, 2009).











3
Unidade I




Oramento Escopo





Tempo


Figura 1: Tringulo do projeto


Os projetos podem ter as mais variadas formas e tamanhos,
conforme exemplos abaixo:

Grandes e pequenos:

construir o prdio mais alto do mundo, o Burj Dubai
5 (Como Tudo Funciona), um projeto;

gerar um relatrio mensal sobre vendas tambm um
projeto.

Ter diversas pessoas ou apenas um:

treinar todos os funcionrios de uma empresa em ITIL
10 um projeto;

reorganizar sua mesa no escritrio um projeto.

Denido por um contrato legal ou um acordo informal:

um contrato denindo a instalao de um sistema
dene um projeto;

15 uma promessa informal para instalar um antivrus no
computador de sua me dene um projeto tambm.

Negcio ou pessoal:

conduzir o direcionamento anual do departamento de
vendas um projeto;

20 planejar o aniversrio da sua lha tambm um
projeto.











4
GERENCIAMENTO DE PROJETOS DE TI


Diante das informaes apresentadas, podemos ver que
no interessam quais so as caractersticas do projeto, mas,
sim, os ingredientes que um projeto deve ter: escopo, tempo e
oramento.

5 Muitas vezes, o termo projeto confundido com processo,
que uma srie de rotinas para executar uma determinada
funo, ou mesmo programa, que dene uma srie de objetivos
para um projeto especco que nunca ser completamente
nalizado.


1.2 Gerenciamento de projeto


10 Como j foi dito, o gerenciamento de projeto a aplicao de
conhecimento, habilidades, ferramentas e tcnicas s atividades
do projeto para atender aos seus objetivos, desde seu incio
at o seu fechamento. De uma forma geral, podemos denir o
gerenciamento de projetos em trs operaes bsicas:

15 planejamento: especica os resultados desejados,
cronograma e recursos necessrios;

organizao: dene as responsabilidades e funes de
cada recurso;

controle: efetua o controle do projeto atravs da
20 monitoraodasatividades, problemasecompartilhamento
das informaes.

De acordo com o PMBOK, o gerenciamento de projetos
realizado por meio da aplicao e da integrao dos 42 processos
de gerenciamento de projetos agrupados logicamente em cinco
25 grupos:

iniciao;

planejamento;

execuo;











5
Unidade I


monitoramento e Controle; e

encerramento.

Gerenciar um projeto tipicamente inclui a identicao
dos requerimentos (necessidades), avaliar as necessidades e
5 expectativas das partes interessadas no projeto (stackholder)
e equilibrar restries do projeto quanto ao escopo, qualidade,
cronograma, oramento, recursos e risco.

Para executar um gerenciamento de projeto de sucesso so
necessrios alguns componentes, como:


10 informao: deve ser precisa, atual para o planejamento
do projeto;

comunicao: deve ser clara, aberta e transparente com
todos os membros do projeto;

compromisso: todos os membros devem ter compromisso
15 com o projeto para entregar ou produzir os resultados
esperados dentro do prazo e do oramento denidos.

Devido prpria natureza dos projetos terem um incio e um
m, alguns desaos podem ser encontrados, como:

novas necessidades: muitas vezes, durante o
20 desenvolvimento do projeto, novas necessidades surgem
e estas podem conitar ou mesmo ser inadequadas, assim
o gerente de projetos deve avaliar cada necessidade;

novas pessoas ou times: mesmo em pequenos projetos
o gerente de projeto tem que lidar com diversas pessoas
25 ou mesmo times, que muitas vezes nunca trabalharam
juntos, tendo cada um forma de comunicao prpria
ou procedimentos diferentes para a execuo de tarefas.
Diante disso, cabe ao gerente de projeto denir quais sero
os meios de comunicao e processos a serem seguidos
30 por todos os componentes do projeto;











6
GERENCIAMENTO DE PROJETOS DE TI


sem autoridade direta: este um problema que afeta
diretamente o gerente de projeto, pois muitas vezes ele
no a autoridade direta sobre um indivduo, pois este
possui outra liderana.


1.3 O gerente de projeto

5 Este prossional tem o objetivo de gerenciar o projeto,
de forma que raramente participa das atividades diretas que
produzem os resultados, pois tem a funo de avaliar o progresso
das atividades e, atravs de variveis como qualidade, custo e
prazo, vericar seus desvios.


10 O cargo de gerente de projeto inuenciado pela estrutura
organizacional no qual o projeto est inserido e pelas disciplinas
envolvidas. Para cada situao especica, ser exigido do gerente
de projeto estilos e habilidades diferentes como pr-requisitos
para seu sucesso.

15 Por que o gerente de projeto pea fundamental no
sucesso? De acordo com uma pesquisa feita pelo Standish Group
International (The Standish Group) em 2008, parte dos mais de
US$ 250 bilhes investidos todos os anos em aplicaes em TI
desperdiada: 31% dos projetos so cancelados antes de seu
20 trmino; 88% ultrapassam seu prazo, oramento ou ambos.

O grco da gura 2 demonstra os projetos que foram bem

sucedidos (succeeded), os que fracassaram (failed) e os que
foram concludos fora do prazo, oramento ou com poucas
funcionalidades (challenged) no perodo entre 1994 e 2000.

Project resolution history (19942000)


2000
28% 23% 49%


1998


1996


1994
26% 28% 46%


27% 40% 33%


16% 31% 53%


Succeeded
Failed
Challenged


0% 20% 40% 60% 80% 100%


Figura 2: Standish Group Report

Fonte?
7
Unidade I

Administrao

Para Kerzner (2009), existem dez importantes habilidades
inerentes ao gerente de projeto, denidas por meio de pesquisas
e experincias, conforme tabela 1.


Habilidades Caractersticas

Construo de equipes
Capacidade de formar e gerenciar equipes de
trabalho.
Liderana
Capacidade de inuenciar a equipe e todos os

envolvidos no projeto.

Resoluo de conito
Capacidade de identicar e resolver os conitos no
mbito do projeto.
Competncia tcnica
Capacidade de coordenar as aes tcnicas do

projeto.
Planejamento Capacidade de elaborar planos e execut-los.
Organizao
Capacidade de estabelecer os critrios de trabalho no
mbito do projeto.
Empreendedor
Capacidade de gerar e gerenciar negcios para o

projeto.

Capacidade de desenvolver tcnicas de controle,
oramento, etc.
Capacidade de gerenciar as interfaces com todos os
Suporte gerencial envolvidos no projeto, principalmente com a alta
administrao.
Alocar recursos
Capacidade de estabelecer os recursos necessrios s

vrias fases do projeto.


Tabela 1: Habilidades do gerente de projeto


De uma forma geral, o gerente de projeto necessita de muito
5 entusiasmo, fora e aptido para sobrepor as resistncias impostas
pelos interesses tcnicos e polticos. Sempre que possvel,
este deve ser algum que j tenha um tempo na organizao
e possua uma posio proporcional a um gerente funcional,
com o qual ir negociar. Quando um gerente de projetos um
10 coordenador dentro de uma estrutura funcional, ou gerente em
uma estrutura matricial, ele ter autoridade incompleta sobre
sua equipe de projeto.
















8
GERENCIAMENTO DE PROJETOS DE TI


1.4 Ciclo de vida de um projeto


Como j apresentado, todo projeto temporrio, assim
possui um ciclo de vida denido, conforme pode ser visto na
gura abaixo:








Conceber
(ideia)
Denir
(plano)
Iniciar
(time)
Executar
(trabalho)
Fechar
(encerrar)








Figura 3: Ciclo de vida de um projeto


1.4.1 Conceber

Todo projeto comea com uma ideia. Esta pode ter vindo
5 de um cliente, do seu chefe, ou mesmo voc ter pensando em
uma nova maneira de fazer um processo ou a ideia de lanar
um novo servio no mercado. Geralmente, esta fase informal,
pois consiste apenas de discusses entre algumas pessoas para
alinhar a ideia e decidir os caminhos a tomar.

10 Para que a diretoria possa autorizar ou decidir se seguiro
com a ideia de forma a criar um projeto, basicamente precisam
responder a duas perguntas:


1. Devemos fazer isso? Quais so os benefcios esperados
versus o valor gasto?

15 2. Podemos fazer isso? O projeto tecnicamente vivel?
Existem recursos para execut-lo?











9
Unidade I


Se obtiver respostas positivas para as questes, pode-se
passar para prxima fase e denir o plano para o projeto.

importante ressaltar que nesta fase tambm necessrio
fazer uma anlise de custo-benefcio, de forma a identicar
5 quais os custos totais do projeto e qual ser o benecio. claro
que neste momento no possvel estimar os custos de forma
exata, porm temos de ter nmeros prximos que oriente a
tomada de deciso.


Um exemplo de ideia nesta fase a seguinte: imagine que sua
10 organizao utiliza um software pago que a cada trs anos deve
ser substitudo por uma verso atualizada, porm voc identica
um software gratuito (open source) que atende as necessidades
de sua empresa. Voc, ento, faz uma breve pesquisa sobre este
software e descobre que grandes organizaes o utilizam e que
15 existe uma empresa que presta suporte, possibilitando, assim,
realizar um contrato para eventuais problemas por R$ 10.000,00
ao ano.


Sua organizao tem aproximadamente mil (1000)
colaboradores e todos utilizam o software pago cujo valor de
20 R$ 100,00 por licena, j incluindo o suporte do primeiro ano,
porm o suporte do 2 e 3 anos custam mais R$ 15.000,00 por
ano. Desta forma, poderamos fazer a seguinte avaliao:


Software Pago Software Gratuito

Valor licena
Valor suporte anual
R$ 100,00
R$ 15.000,00
1

-
R$ 10.000,00




Custo para 1.000 usurios R$ 100.000,00 -
Custo manuteno 1 ano - R$ 10.000,00
Custo manuteno 2 ano R$ 15.000,00 R$ 10.000,00

Custo manuteno 3 ano
Custo total
R$ 15.000,00
R$ 130.000,00
R$ 10.000,00
R$ 30.000,00


Tabela 2: Comparao entre softwares

1
No primeiro ano no cobrada a manuteno.










10
GERENCIAMENTO DE PROJETOS DE TI


Atravs da tabela acima conseguimos vericar que a
substituio do software pago pelo gratuito pode gerar um
benefcio para a empresa na ordem de R$ 100.000,00, assim
provvel que seja um candidato a projeto, porm importante
5 avaliar outros itens como:

estimativa de custos e tempo para implementar a mudana
de software;

custo com treinamento para os usurios utilizarem o novo
software.

10 Devido aos itens relacionados anteriormente, pode ser que
o custo para implementar o novo software que acima dos R$
130.000,00, assim caber uma anlise mais profunda da diretoria
da empresa a m de vericar se vivel sua implementao,
considerando um retorno a longo prazo, ou seja, seis anos. Em seis
15 anos (duas atualizaes, a empresa gastaria aproximadamente
R$ 260.000,00 contra os R$ 60.000,00 mais treinamentos.

1.4.2 Denir

Nesta fase, deve-se denir e escrever os planos para atingir
os resultados do projeto mostrando como voc e seu time vo
fazer o projeto acontecer. Os seguintes itens devem ser includos
20 no seu plano:

uma pequena introduo sobre as razes que conceberam
o projeto, de forma que todos os envolvidos tenham o
mesmo entendimento;

uma descrio detalhada dos resultados esperados;

25 uma lista com todas as tarefas a serem executadas;

as funes e responsabilidades de cada membro do
projeto;

um cronograma detalhado do projeto;












11
Unidade I


oramento para recursos, equipamentos, etc.;

pressupostos conhecidos como Assumptions.

1.4.3 Iniciar

Aqui o trabalho do projeto inicia com a alocao dos recursos
(indivduos) que iro trabalhar no projeto, atravs da negociao
5 de sua disponibilidade e funes dentro do projeto.

extremamente importante explicar para todos os recursos
envolvidos e as tarefas que devero ser executadas por cada
integrante dentro do projeto, de forma que todos possam ter
uma ideia macro das atividades do projeto. Nesta fase, novas
10 tarefas podem surgir devido ao conhecimento mais tcnico dos
participantes, muitas vezes alterando de forma expressiva o
cronograma. Diante disso, o gerente de projetos ter um grande
desao para negociar novas atividades, de forma a adequar ao
cronograma j estabelecido e resolver conitos entre membros
15 da equipe.

Nesta fase, o gerente de projetos ainda precisa denir os
sistemas e como ir fazer o mapeamento das atividades do
projeto, de forma a ter uma viso do seu andamento, custos,
etc.


1.4.4 Executar

20 Finalmente o projeto tem seu incio, ou seja, aps todo o
trabalho de denio de escopo, obteno de requerimentos,
criao de cronograma, denio de recursos, gerenciamento de
conitos, etc., os indivduos comeam a trabalhar nas tarefas do
projeto.

25 Nesta fase, extremamente importante acompanhar cada
atividade e confrontar com o que foi previamente planejado
para vericar se est ocorrendo conforme os planos.












12
GERENCIAMENTO DE PROJETOS DE TI


Diversos problemas podem surgir, assim, necessrio corrigir
os desvios e manter todos os membros do time informados.


1.4.5 Fechar

A fase de fechamento consiste basicamente na entrega do
projeto ao cliente nal de forma a obter sua aprovao para
5 encerramento do projeto. No entanto, para obter esta aprovao
do cliente ser necessrio demonstrar que os objetivos
previamente estabelecidos foram alcanados dentro do tempo
e do custo esperados.

Em todo projeto, pequenos ou grandes, sempre temos
10 surpresas que acontecem durante sua fase de execuo,
assim fundamental que tudo seja muito bem documentado,
principalmente as lies aprendidas durante sua execuo, pois
podero ajudar em um prximo projeto.


1.5 Passos fundamentais para a gerncia de
projeto

De acordo com Fernando (Barbi), existem sete passos bsicos
15 para o gerenciamento de projetos de TI, que podem fornecer
maior controle e aumentar assim o sucesso do projeto.


1.5.1 Metodologia

necessrio escolher uma metodologia que ser aplicada
ao projeto. Atualmente, existem diversas metodologias para o
desenvolvimento de projetos como: CMMI, SCRUM, RUP, XP,
20 MSF.

Cada metodologia tem caractersticas prprias (apesar de
terem a mesma base) e deve ser utilizada para um determinado
tipo de projeto. Desta forma, enquanto a metodologia CMMI
mais adequada para o desenvolvimento de software, ela pode
25 no ser ideal para o projeto de desenvolvimento de um carro.











13
Unidade I


Em linhas gerais, as metodologias de projeto seguem a
seguinte estrutura:

observao e anlise: denir problema, objetivo,
requerimentos, etc.;

5 planejar e projetar: criar o planejamento das atividades
do projeto;

construir e executar: pode-se criar um prottipo e ento
passar para construo nal.


O principal motivo de se usar uma metodologia utilizar
10 regras para conduzir um projeto com sucesso, pois a metodologia
o estudo dos mtodos, e os mtodos so a forma como vamos
executar uma tarefa.


1.5.2 Comunicao

No s o peixe que morre pela boca. Esta uma frase
muito conhecida e pode ser aplicada com sucesso aos projetos,
15 pois a boa comunicao fator muito importante de sucesso em
um projeto. Boatos ou outras formas de rudos podem prejudicar
o andamento do projeto.


Para uma boa comunicao necessrio que o gerente crie
um plano, mantendo o time informado por meio de reunies,
20 e-mails ou boletins. Toda informao deve ser amplamente
divulgada, principalmente quando se trata de um problema,
pois deve-se mostrar conhecimento acerca do mesmo e quais
solues sero empregadas.

1.5.3 Escopo e atividades

De acordo com o dicionrio Michaelis, escopo objetivo
25 ou propsito, assim podemos definir que o escopo ser o
conjunto de atividades que o projeto se prope a executar.
Diante disto, fundamental a correta identificao do escopo











14
GERENCIAMENTO DE PROJETOS DE TI


para que um mapeamento das atividades seja feito de forma
concisa.

A denio de escopo uma tarefa muito difcil, pois em
muitos casos parece que o escopo innito, por ele ser muito
5 aberto. O ideal sempre fechar o escopo ao mximo para
assegurar a denio do produto nal.


Com o escopo denido, hora de identicar as atividades
que sero necessrias para atingir o objetivo, denindo qual o
esforo necessrio a cada uma, de forma a gerar uma WBS. Um
10 exemplo de alto nvel pode ser visto na tabela abaixo:


Prossional Tarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Custo Total
Gerente de projeto 40h 20h 55h 66h R$ 110,00 R$ 19.910,00
Lder de projeto 60h 40h 40h 80h R$ 110,00 R$ 24.200,00
Programador 10h 80h 80h 80h R$ 60,00 R$ 15.000,00
Tabela 3: Atividades e custos de projeto


Com isso podemos identicar os custos de cada prossional
no projeto, bem como os custos para cada atividade. O ideal criar
um detalhamento muito maior do que o demonstrado acima para
aumentar o controle sobre as atividades e os custos envolvidos.

15
Um problema frequente nos projetos a mudana de escopo
durante sua execuo. Isto deve ser evitado a m de proteger
o projeto e garantir a entrega. Quando a mudana de escopo
inevitvel, necessrio adicionar as tarefas ao projeto de forma
a visualizar os aumentos de custo e prazo para entrega, obtendo
20
assim aprovao do cliente.


1.5.4 Recursos envolvidos no projeto

Todas as pessoas envolvidas no projeto so conhecidas como
stackholders, que so os membros da equipe de projeto, clientes,
fornecedores, etc. A pessoa que representa o cliente (pode ser











15
Unidade I


externo ou interno) conhecida como sponsor, e geralmente
ela quem dene o escopo e o prazo de entrega de um projeto.

Se possvel o gerente de projetos deve fazer a escolha
dos recursos que desenvolvero o projeto de forma a obter
5 os melhores prossionais disponveis e com a competncia
adequada a cada tarefa.


Em muitos projetos fundamental a presena de um lder,que
um prossional snior com muita bagagem tcnica, podendo,
assim, melhor direcionar a equipe tcnica.


1.5.5 Desenvolvimento do cronograma

10 O desenvolvimento do cronograma do projeto fundamental
para entender as atividades e como avaliar o andamento do
projeto. O problema que muitas vezes o desenvolvimento do
cronograma feito pelo gerente de projetos ou indivduos em
cargos gerenciais, criando assim um cronograma falho, pois
15 muitas atividades no reetem a realidade.

fundamental que o cronograma seja criado pelas pessoas
que executam a tarefa, ou seja, que pem a mo na massa. Estas
conseguiro identicar melhor a durao, interdependncia e o
responsvel por cada atividade.


20 Quando no for possvel desenvolver o cronograma com
estes indivduos de suma importncia, no mnimo, efetuar
uma reviso do cronograma com todo o time a m de melhor
identicar as propriedades das atividades.

1.5.6 Riscos

Com as tarefas bem denidas, todos sabem o que deve ser
25 feito, porm ainda importante identicar os possveis riscos ao
projeto, criando uma lista de fatores de risco e um plano para
lidar com eles.











16
GERENCIAMENTO DE PROJETOS DE TI


Um exemplo de risco seria a compra de um equipamento
importante cujo prazo de entrega 30 dias. Qual seria o
procedimento caso o equipamento leve 60 dias para chegar? O
projeto ser atrasado? Quais sero as penalidades?

5 Monitorar os riscos do projeto muito importante para
identicar quando iro acontecer e quais sero as aes tomadas
para minimizar seu impacto no projeto. possvel tambm
avaliar a probabilidade de ocorrncia de um risco.


1.5.7 Incio e m do projeto

Como j foi dito, todo projeto precisa ter incio e m, assim
10 importante formalizar o incio do projeto com o sponsor,
atravs de uma reunio, e-mail ou mesmo um contrato, de
forma a sinalizar o incio das atividades com todos os membros
do time.


Da mesma forma que o incio do projeto, fundamental
15 formalizar o seu trmino demonstrando os resultados alcanados,
obtendo assim a formalizao de aprovao do sponsor.


Aps a nalizao do projeto interessante realizar uma
reunio com a equipe para identicar os problemas, erros e
acertos e gerar um documento chamado de lessons learned, ou
20 seja, lies aprendidas que podero ser teis em novos projetos,
evitando o acontecimento dos mesmos erros ou problemas.


1.6 Mnimo necessrio para o gerenciamento
de projetos

Todos os processos associados ao planejamento de projetos
tm como principal objetivo elaborar documentos que denem
o equilbrio entre o escopo, que o que deve ser feito, o tempo
25 necessrio para realizar o que pedido no escopo e por m o
custo total de projeto, que o valor gasto para execuo do
projeto.











17
Unidade I I



Esc

opo





fundamental lembrar que outras reas devero ser
trabalhadas no planejamento, como:

gesto de riscos;

gesto de qualidade;

5 aquisies;

contrataes;

comunicao;

etc.

De uma forma simples, a gura abaixo consegue demonstrar
10 os principais pontos de um projeto:



Tempo






Riscos






Custos
Plano
integrado
Unidade I I


2 MICROSOFT PROJECT


O Project foi criado pela Microsoft em 1985 como um software
para gesto de projetos. Desde sua criao o software vem sofrendo
profundas mudanas. Hoje o Project possui funcionalidades como:


10 durao de tarefas (datas, calendrios);

grco de Gantt;

modelo probabilstico;

diagrama da rede;

custos (xos, no xos, outros);

15 relatrios;

etc.
Unidade I I
25





2.1 Apresentao do Microsoft Project

Antes de comear a demonstrar como utilizar a ferramenta
importante fazer o download. A Microsoft disponibiliza o
download gratuito para alunos de universidades atravs do
site Faculty Connection em <http://www.microsoft.com/
5 education/FacultyConnection> ou tambm pode ser baixada
a verso de avaliao no site do Project em <http://ofce.
microsoft.com/pt-br/project/default.aspx>.

Abaixo, a imagem com a tela principal do Project:

Barra de

ttulo
Barra de

ferramentas

Barra de
menu














Incluso de
tarefas
Barra de
entrada







Diagrama de
Gantt















Barra de
modos



Figura 7: Tela principal do Project


Barra de
rolagem

Diviso de
painis
Unidade I I
26



2.2 Criando um novo documento de projeto


Como em qualquer aplicativo Microsoft Ofce, ao executar
o Microsoft Project um novo projeto aberto automaticamente,
chamado Project1.

Caso deseje criar um novo projeto, selecione Arquivo na
5 barra de menu e ento selecione novo arquivo.

Selecione a visualizao Grco Gantt ou Gantt Chart
que o tipo padro para trabalhar com projetos no Microsoft
Project. Neste modo de visualizao a tela divida em duas
partes: na esquerda, possvel ver a tabela de atividades e, na
10 direita, o grco Gantt, conforme apresentado em detalhes
abaixo:



Figura 8: Detalhes da tabela de tarefas


campo indicador: este campo representado pela
letra i e coloca informaes sobre as atividades, como
porcentagem nalizada, etc.

15 taskname: descrio ou nome da atividade;

duration: tempo de durao da atividade. Pode ser dada
em horas, dias, etc.;

start: data de incio da atividade;
Unidade I I
27



nish: data de trmino da atividade;

predecessors: informao sobre atividades predecessoras,
ou seja, atividades do qual a atividade depende para
iniciar;

5 resource names: nome dos recursos alocados para cada
atividade. So as pessoas responsveis pela execuo da
atividade.

Aps a criao do arquivo e entendimento dos principais
campos utilizados necessrio cadastrar as informaes
10 principais do projeto acessando o a opo Projeto na barra de
menu e em seguida Informaes de Projeto. A gura abaixo
demonstra a tela de informaes do projeto:



Figura 9: Informaes do projeto


start date: data de incio do projeto;

nish date: data de trmino do projeto. Geralmente no
15 pode ser alterada, pois atualizada atravs das tarefas do
projeto;
Unidade I I
28



schedule from: determina se o projeto deve ter suas
tarefas baseadas no incio ou m do projeto;

current date: determina a data atual do projeto;

status date: pode-se determinar uma data para status do
5 projeto, assim o Project poder calcular as tarefas, custos,
etc., at a data de status;

calendar: dene qual o calendrio de trabalho ser
utilizado pelo projeto. Aqui possvel denir dias e horas
de trabalho;

10 priority: determina a prioridade padro das tarefas;

statistics: apresenta a caixa de dilogo Statistics com
informaes do projeto.


Com estas informaes j possvel comear a trabalhar no
projeto.


2.3 Como criar um cronograma no Project?


15 Se trabalharmos com o exemplo de projeto utilizado
na Unidade I, onde foi discutida a troca do software pago
pelo software livre, poderamos pensar nas seguintes
atividades:


# Atividades Durao Predecessor Responsvel
1 obter software 1d - Engenheiro
2 instalar software 1d 1 Engenheiro
3 congurar software 1d 2 Engenheiro
4
criar pacote para instalao
silenciosa
5d 3 Engenheiro

5
instalar pacote em uma est
de teste
o

5d

4

Help Desk
6 efetuar testes de software 5d 5 Usurio

Tabela 8: Atividades do projeto software gratuito
Unidade I I
29



Fazendo uma rpida avaliao na tabela acima, podemos
identificar que importante descrever a atividade, sua
durao, predecessor e responsvel. Sem a durao fica
difcil identificar quando o projeto ser finalizado e sem o
5 predecessor, no sabemos que tarefas podem ser executadas,
pois impossvel realizar a configurao do software sem
que o mesmo esteja instalado. Neste projeto a durao est
expressa em dias, pois os recursos no esto dedicados a
este projeto, ou seja, estamos compartilhando o tempo dos
10 recursos com outros projetos.


O Project funciona de forma similar, assim, colocando estas
atividades no programa, teramos algo semelhante gura
abaixo:



Figura 10: Tarefas no Microsoft Project


Pode-se notar que ao denir a durao da atividade e os
15 predecessores no Project, ele automaticamente calcula as datas
de incio e m de cada atividade, gerando inclusive um mapa
que torna mais visual o trabalho, conforme gura abaixo:



Figura 11: Grco com relacionamento entre atividades
Unidade I I
29





Supondo que estas atividades faam parte do piloto,
ou seja, o objetivo apenas verificar o funcionamento do
aplicativo em um ambiente de testes, poderamos organizar
e criar tarefas principais, que tambm so chamadas de
5 milestone, utilizando a ferramenta de identar (Alt + Shitft
+ Direita). Desta forma poderia criar uma atividade inicial
chamada piloto e identar as demais para que elas fiquem
abaixo da atividade piloto, que seria uma espcie de
atividade pai.















Figura 12: Criando um milestone

10 Note que todas as atividades anteriores fazem parte
de uma atividade maior chamada de Fase Piloto. Nesta
atividade no definimos predecessores nem recursos, pois ela
a somatria de todas as atividades filho.


Agora, que denimos as atividades da fase piloto, vamos
15 denir as atividades necessrias para a instalao no ambiente
de produo. Como a empresa utiliza ITIL, ser necessrio passar
pelo processo de mudana antes de disponibilizar o aplicativo
aos usurios. Ser necessrio tambm providenciar treinamento,
que estar disponvel atravs de e-learning ou treinamento
20 presencial.

Desta forma a gura a seguir representa uma sugesto de
cronograma:
Unidade I I
31































Figura 13: Projeto com fase piloto e de implantao


Neste momento o projeto comea a tomar forma, pois
denimos duas atividades-chaves, piloto e implantao e
denimos mais duas atividades-chaves dentro da fase de
implantao que o processo de mudana necessrio
5 implementao do sistema e o treinamento necessrio para que
os usurios saibam como utilizar o novo software. Note que ca
fcil identicar o incio e o trmino do projeto.

























Figura 14: Grco com detalhes das atividades do projeto
Unidade I I
31



Atravs da gura 8 possvel visualizar de forma fcil quais
atividades esto no caminho crtico do projeto e quais no esto.
As atividades circuladas podem ter atrasos que no impactam a
entrega do projeto nal, porm, todas as demais, se atrasarem,
5 afetaro o prazo de entrega.

Para demonstrar ao Project que uma atividade um

milestone do projeto, basta abrir as propriedades da atividade e
marcar como milestone, conforme gura abaixo:



Figura 15: Denindo milestone no Project


2.4 Acompanhando o progresso das
atividades

possvel adicionar uma coluna que indica a porcentagem
10 concluda da atividade, assim o gerente de projeto consegue
acompanhar o andamento das atividades e vericar se as
mesmas sero nalizadas dentro do prazo estipulado.
Unidade I I
33






























Figura 16: Avaliao de trabalho das atividades


2.5 Controlando os custos das atividades e
projeto


O Project tambm pode ser utilizado para controlar os custos
do projeto, pois possvel informar os valores de cada prossional
ou recurso e ento, atravs da concluso das atividades, vericar
quanto j foi gasto no projeto.

5
Para abrir a janela para assinalar recursos, pressione Alt +
F10 e a seguinte janela ser aberta:



Figura 17: Assinalando recursos
Unidade I I
34



Note que esta tela pode ser mostrada para cada atividade,
porm uma vez congurado os valores dos prossionais, todas
as atividades utilizaro estes valores. Clicando duas vezes em
cima do recurso, ser exibida a janela de informaes do recurso,
5 onde possvel denir as seguintes informaes:

nome do recurso;

e-mail;

conta do Windows;

disponibilidade do recurso;

10 custos do recurso (rate)

anotaes;

etc.

Na gura abaixo foi denido um valor de R$ 100,00 por
hora, assim o projeto assumir este valor para todas as horas do
15
engenheiro. Note que o ideal assinalar os nomes das pessoas
e as atividades e no times e/ou siglas, porm utilizamos esta
forma aqui para facilitar o entendimento.



Figura 18: Custo do recurso
Unidade I I
35



2.6 Gerando relatrios sobre o projeto


Atravs da opo de relatrios possvel gerar uma
infinidade de relatrios grficos ou textos que auxiliaro
no gerenciamento do projeto e reportaro para os
stackholders.

5 Os relatrios mais comuns so:

viso geral do projeto;

atividades atuais do projeto;

custos do projeto;

tarefas assinaladas para cada recurso;

10
carga de trabalho sobre cada funcionrio;

etc.

Task Status Report



Total
Work 360
Cost R$ 8.800
9%

Tasks 01

Project1
Work 0
Cost R$ 0
0%
Fase piloto
Work 144
Cost R$ 6.400
22%
Fase de
implantao
Work 216
Cost R$ 2.400
0%

Figura 19: Exemplo de relatrio grco


2.7 Formas de exibio


O Microsoft Project possui algumas formas de visualizar as
tarefas do projeto:
Unidade I I
36



2.8 Calendrio


As tarefas so exibidas no formato de agenda contando os
dias da semana, onde so demonstradas as atividades.



Figura 20: Visualizao atravs de calendrio


2.9 Grco de Gantt

O grco de Gantt constitudo por uma tabela de atividades
do projeto e um grco demonstrando a ligao entre as
5
atividades no tempo do projeto. Esta a visualizao padro
utilizada no Project.



Figura 21: Visualizao de tarefas e grco Gantt
Unidade I I
37



2.10 Diagrama de rede


Exibe as tarefas do projeto em caixas ou ns, onde as linhas
de ligao entre os ns representam o elo entre as atividades
sucessoras e predecessoras.



Figura 22: Visualizao pelo diagrama de rede


2.11 Grco de recursos

Exibe a colocao de recursos, trabalho ou custo de um
5
recurso durante um perodo de tempo.




Figura 23: Visualizao de alocao de recursos
GERENCIAMENTO DE PROJETOS DE TI
39



2.12 Planilha de recursos


Exibe as informaes sobre cada recurso, como: taxa de
pagamento, quantidade de pagamento, quantidade de horas de
trabalho, custo inicial, etc.



Figura 24: Visualizao de custos dos recursos

GERENCIAMENTO DE PROJETOS DE TI
40





Unidade III



3 GESTO DOS RISCOS EM TI

Para poder gerenciar os riscos necessrio
primeiramente entender o que o risco. Assim, risco
pode ser definido como a combinao da
probabilidade de um evento acontecer e suas
consequncias ou simplesmente a chance de algo
5 acontecer.

Em todos os projetos sempre existe um potencial para

eventos e consequncias que constituem oportunidades para
benefcios ou ameaas ao sucesso.

Diante disso, o gerenciamento de riscos tornou-se
10
fundamental, tanto do lado positivo quando do lado
negativo, para o bom andamento de qualquer projeto de
TI.

fundamental o entendimento da diferena entre gerncia
de riscos e anlise de riscos, assim segundo Alencar (Alencar &
Schimtz, 2006), temos:

15
gerncia de riscos: dene uma maneira
previsvel para lidar com os imprevistos,
fazendo com que os possveis cenrios futuros
quem dentro de uma faixa de
variabilidade aceitvel;

anlise de riscos: dene um conjunto de atividades
20 que visam identicar os fatores de risco,
avaliar seu possvel impacto e denir aes a
serem executadas para reduzir ou eliminar a
inuncia destes fatores no resultado
desejado.
GERENCIAMENTO DE PROJETOS DE TI
41



O gerenciamento de risco uma disciplina que est se
desenvolvendo rapidamente, possuindo assim vrias vises
e descries sobre o que envolve a gerncia de riscos, como
deve ser conduzida e para que serve. Assim, alguns padres
5 foram escritos pela ISO no documento ISO/IEC Guide 73 Risk
Management Vocabulary Guidelines for use in Standards
que um guia padro para o gerenciamento de riscos.

O objetivo do gerenciamento de riscos em projeto obter
uma entrega com maior qualidade em termos de cronograma,
10 custos e operao nal.

O processo de gerenciamento de risco de projeto deve
garantir que:


todos os riscos signicantes para o sucesso do projeto
foram identicados;

15
os riscos identicados foram compreendidos em termos
das consequncias nais;

realizada uma relao individual dos riscos em relao a
todos os riscos para ajudar a denir prioridades;

estratgias para tratar os riscos levam em conta
20 oportunidades para enderear mais de um risco;

o processo e o tratamento de riscos sejam efetuados de
forma rentvel.


3.1 O caso Titanic


Todos conhecem a histria do navio Titanic que naufragou
no dia 15 de abril de 1912 levando a vida de 1522 pessoas
25 das 2227 que estavam a bordo. Mas o que de fato aconteceu?
Esta uma pergunta que vem tentando ser respondida h
muito tempo, por isso vamos fazer uma breve anlise dos
fatos.
GERENCIAMENTO DE PROJETOS DE TI
42



O Titanic era o maior navio transatlntico do mundo com uma
extenso total de 277,7 metros e era considerado inaufragvel
pela mdia. Sabemos que hoje em dia todo navio construdo
passa por um longo perodo de testes a m de avaliar e tomar
5 conhecimento de todo o funcionamento da embarcao bem
como testar planos de emergncia. O Titanic passou por um
perodo de testes de apenas meio-dia, onde constatou-se que
para parar o navio a partir de uma velocidade de cruzeiro de
33 km/h eram necessrios 3 minutos e 15 segundos, percorrendo
10 uma distncia de quase 1 Km.

Em sua viagem inaugural, mesmo o capito sabendo que
para parar o navio para desviar de algo levaria mais de 3 minutos
e percorreria quase 1 km, o navio manteve uma velocidade de
20 ns ou 37 km/h. A alta velocidade tinha o objetivo de tentar
15 bater o recorde de travessia do Atlntico, colocando assim o
navio nas primeiras pginas dos jornais.


Como naquela poca no existia radar, era necessrio o uso
de binculos por marinheiros que cavam no cesto da gvea
1
para observar perigos a frente do navio.


20 No dia 12 de abril o Titanic recebeu o primeiro aviso de
iceberg
2
por um transatlntico francs. Em 13 de abril recebeu
outro aviso de um transatlntico britnico. No dia 14 de abril,
o Titanic recebeu seis avisos de iceberg a frente, sendo o
ltimo s 21 horas e 40 minutos, e mesmo assim no reduziu a
25 velocidade.

No dia do acidente, os marinheiros responsveis pela vigia
no cesto da gvea no estavam utilizando binculos, assim a
visualizao de bloco de gelo se tornava mais difcil.


Outro problema observado foi que o navio no possua botes
30 salva-vidas sucientes, sendo que apenas 53% dos passageiros
poderiam ser atendidos pelos botes em caso de necessidade.

1
Ponto de observao no mastro mais alto do navio.
2
Blocos de gelo.
GERENCIAMENTO DE PROJETOS DE TI
43



Avaliando os pontos apresentados, podemos entender que
diversos fatores contriburam para o acontecimento da tragdia,
assim, se o capito tivesse achado que naquela velocidade no
seria possvel desviar de um iceberg, talvez tivesse diminudo a
5 velocidade. Se o ocial responsvel pelos marinheiros soubesse
que os mesmos estavam sem binculos, poderia ter enviado um
par de binculos. Se a empresa responsvel pelo barco soubesse
que, em caso de acidente, no haveria botes salva-vidas para
todos talvez pudesse ter colocado mais botes e treinado as
10 pessoas para sua utilizao.


importante observar que a velocidade do navio, a ausncia de
binculos e a quantidade insuciente de salva-vidas constituem
o fator de risco, que qualquer evento que venha prejudicar
um projeto, que neste caso era a viagem entre Southampton e
15 Nova York.

Diante deste exemplo, se o capito do navio (gerente de
projeto) e os ociais (equipe de projeto) tivessem identicado
previamente os fatores de risco, poderiam ter criado planos
de conteno de forma a reduzir as chances de um fator de
20 risco acontecer. Poderiam tambm ter criado um plano de
contingncia que tem a nalidade de reduzir o impacto dos
fatores de risco.


Analisando este caso ca claro como o gerenciamento de
riscos pode contribuir para o sucesso de um projeto, pois se
25 o capito tivesse todas as informaes acerca dos fatores de
risco, provavelmente teria reduzido a velocidade do navio e
atentado para o fato dos marinheiros utilizarem binculos, o que
provavelmente teria evitado a coliso do navio com o iceberg.


3.2 O processo de gerenciamento de riscos


O processo de gerenciamento de riscos a combinao
30 da anlise e do controle de risco, onde temos a seguinte
composio:
GERENCIAMENTO DE PROJETOS DE TI
44


Monitorao FR
P
r
o
c
e
s
s
o

d
e

g
e
r

n
c
i
a

d
e

r
i
s
c
o

P
r
o
c
e
s
s
o

d
e

a
n

l
i
s
e

d
e

r
i
s
c
o



Fatores
crticos de
sucesso

Processo da
gerncia de risco

Executa
contingncias

Processo de controle de risco


Anlise de risco
Controle de risco


Identica objetivos
do projeto
Identica fatores de
risco (FR)
Estima impacto
do FR

Dene resposta
ao FR
Redene plano de
projeto


Figura 25: Processo de gerenciamento de riscos.

Fonte: Prof. Edilson de Andrade Barbosa (Anlise de risco em gerncia de projeto)


Processo de anlise de risco:

identica objetivos do projeto: identica quais so
os objetivos do projeto e seus respectivos critrios de
sucesso;

5 identica fatores de risco: o objetivo identicar
quais so os fatores de risco que podem comprometer
os critrios de sucesso do projeto. Esta atividade
imprescindvel e est diretamente relacionada com a
experincia das pessoas envolvidas no projeto, pois
10 como uma atividade de descoberta, ca muito difcil
criar um modelo capaz de descobrir os fatores de risco
de um projeto;

estima impacto do fator de risco: aps a identicao
dos fatores de risco, torna-se necessrio estimar qual
15 o impacto causado caso o fator de risco venha a
acontecer. tambm muito importante estimar quais
as probabilidades do fator de risco acontecer para
ajudar no tratamento das prioridades;

dene resposta ao fator de risco: com a estimativa do
20 impacto dos fatores de risco necessrio criar um plano
GERENCIAMENTO DE PROJETOS DE TI
45



de resposta, que basicamente pode ter as seguintes
aes:

eliminar o fator de risco: um plano que extermina o
fator de risco do projeto;

5 contingenciar o fator de risco: muitas vezes no
necessrio eliminar um fator de risco do projeto
pelo fato de sua probabilidade de acontecer ser
muito baixa ou mesmo pelo custo para eliminar ser
alto. Cria-se, ento, um plano para tentar minimizar
10
o impacto do fator de risco caso este venha a
acontecer;

ignorar o fator de risco: alguns fatores de risco tm
a probabilidade muito baixa de acontecer, assim
pode-se ignor-los desde que possam ser tratados
15 sem afetar o custo ou prazo do projeto.

redene plano do projeto: com o levantamento das
aes necessrias para resposta aos fatores de risco
(mitigao) novas atividades precisam ser inseridas no
projeto e estas provavelmente vo inuenciar no custo
20
e no prazo do projeto.

Processo de controle de risco:

monitoramento do fator de risco: necessrio que
uma pessoa do time, geralmente o gerente de projetos,
monitore os fatores de risco para sinalizar quando
25 realmente acontece;

executa contingncias: uma vez que um fator de
risco aconteceu, deve-se ento executar o plano de
contingncia criado.


3.3 Avaliao dos riscos


Para gerenciar um risco necessrio conhecer todos os
30 aspectos referentes ao fator de risco, logo imprescindvel
GERENCIAMENTO DE PROJETOS DE TI
46



avaliar o impacto, a probabilidade, a prioridade e o custo para
mitigar o risco.


3.4 Identicao dos riscos

extremamente importante a identicao dos riscos, que
no deve ser confundida com incertezas, que a probabilidade
5 de um fato ocorrer, enquanto o risco avaliado pelo impacto
da ocorrncia de um fato. Para identicar os riscos, as tcnicas
mais utilizadas so:


entrevistas com especialistas: estas pessoas tm
conhecimento suciente para identicar riscos dentro de
10 um projeto;

analogias: fazendo analogias possvel identicar riscos.

Para ajudar na correta identicao dos riscos possvel
construir uma matriz contendo todas as fases do projeto:


Dimenso risco Concepo Desenvolvimento Instalao
Tcnico
Objetivo



Prover alta disponibilidade

Estratgias
Riscos
Alocar recursos com conhecimento
Atraso do projeto pela falta de prossionais


Tabela 9: Matriz de riscos


A tabela acima mostra o exemplo de um projeto em que
15 na fase de desenvolvimento necessrio atingir um objetivo
tcnico, que a criao de um ambiente com alta disponibilidade,
assim como a estratgia para este objetivo, necessrio alocar
um prossional que tenha conhecimento sobre ambiente de
alta disponibilidade. Um possvel risco para o projeto seria no
20 encontrar prossionais qualicados para desenhar a soluo de
alta disponibilidade.
GERENCIAMENTO DE PROJETOS DE TI
47


Desta mesma forma podemos identicar outros objetivos e
riscos associados para qualquer fase do projeto e qualquer tipo
de atividade, sendo ela tcnica, legal, operacional, etc.

Com os riscos identicados necessrio agora identicar se
5 vale a pena mitigar o risco e ento estabelecer prioridades entre
eles. Do ponto de vista nanceiro s vale a pena mitigar o risco
se o custo para mitig-lo for menor que a probabilidade do risco
acontecer multiplicado pelo impacto do risco. Assim, temos:


C<(I x P)

Em que: C = Custo, I = Impacto, P = Probabilidade

Desta forma, suponha que o impacto de um fator de risco
10 acontecer seja de R$ 5.000,00 e sua probabilidade de ocorrer seja
0,2, assim o impacto esperado seria em torno de R$ 1.000,00. Se
o custo para mitigar este risco for maior que R$ 1.000,00, a
mitigao do risco no valeria a pena. Outra conta que pode ser
utilizada o custo para mitigar o risco versus o custo do projeto,
15 assim se o custo de mitigao for maior que o custo do projeto,
no vale a pena mitigar o risco.


GERENCIAMENTO DE PROJETOS DE TI
59


Unidade IV


4 GESTO DA QUALIDADE EM TI

Entregar servios de TI com qualidade uma tarefa
extremamente importante, porm muito difcil, logo um
desao de qualquer CEO. Diante destes desaos, muitas
empresas utilizam processos de gesto da qualidade como ISO
5 9001, CMMI, Cobit, ISO 10006, ISO 9001, entre outros, com o
objetivo de satisfazer aos seus clientes.

A utilizao de processos para gesto da qualidade
inicialmente pode parecer complicada e onerar a operao, mas
a sua maturidade torna a gesto mais simples.

10
De forma a padronizar a gesto da qualidade muitas
organizaes criaram normas tcnicas que estabelecem os
procedimentos e melhores prticas para atingir a gesto de
qualidade, como a famosa ISO 9000.


4.1 Controle da qualidade


Controle da qualidade um processo pelo qual realizada a
15
reviso de todos os fatores envolvidos na produo com nfase
em trs aspectos:

elementos como controles, gerenciamento de tarefas,
processos denidos e bem gerenciados, desempenho e
critrios de integridade e identicao de registros;

20 competncia, tais como conhecimento, habilidades,
experincia e qualicaes;
GERENCIAMENTO DE PROJETOS DE TI
60





elementos de software, tais como a integridade pessoal,
conana, cultura organizacional, motivao, esprito de
equipe e os relacionamentos de qualidade.

Para melhor controlar a qualidade, diversas metodologias e
5 normas foram criadas conforme veremos adiante.

4.1.1 NBR ISO 9001: Sistema de Gesto da Qualidade

A NBR ISO 9001 a norma brasileira baseada na norma
internacional ISO 9001 que dene os requisitos necessrios para
o sistema de gesto da qualidade, conhecido como SQC, em
uma organizao. Desta forma, o principal objetivo da norma
10 prover a conana de que o provedor poder fornecer de forma
consistente e repetitiva, bens e servios de acordo com o que
o cliente especicou.


A norma atualmente utilizada em todo o setor, desde
pequenas a grandes empresas, e cada dia mais comum o uso
15 de termos como qualidade, auditoria, processos, requisitos,
especicaes, conformidades e no conformidades.


A norma ISO baseada no PDCA, que signica: Plan
(Planejar), Do (Fazer), Check (Vericar), Act (Agir), criando um
ciclo contnuo, conforme demonstrado na gura abaixo:


Plan



Act ISO Do



Check



Figura 30: PDCA
GERENCIAMENTO DE PROJETOS DE TI
61



importante claricar que a norma no dene requisitos
sobre a gesto empresarial, ou seja, no dene quais devem
ser as caractersticas de seu produto ou como o mesmo deve
ser produzido. So apresentadas exigncias para gerenciar os
5 requisitos do cliente e garantir que os mesmos sejam atendidos
de forma ecaz.


Um exemplo bsico de aplicao da ISO seria criar um
processo de envio e recebimento de computadores para um
laboratrio. Imagine que a empresa XPTO responsvel pela
10 manuteno de computadores da marca Xingling. Assim, sempre
que um computador levado por um cliente, a empresa registra
os dados do equipamento e do cliente e envia para seu prprio
laboratrio a m de identicar o problema. Uma vez identicado
o problema, a empresa, ento, pode solucion-lo, enviar para a
15 fbrica para soluo ou mesmo registrar como sem soluo.

As tarefas descritas acima sero realizadas inmeras vezes
pela empresa, assim importante que todos os funcionrios
a executem da mesma forma para garantir a consistncia e
repetitividade. Desde modo, a empresa deveria documentar este
20 processo e compartilhar com seus funcionrios para garantir
que todos o conhecem.


A documentao e o compartilhamento dos processos no
garantem que os funcionrios o conhecem e o seguem, assim
necessrio executar auditorias. Elas podem ser comparadas a
25 uma prova, onde o auditor vai vericar se o funcionrio conhece
os processos e os utiliza de forma correta.

A ideia do PDCA garantir a melhoria constante do
processo, pois inicialmente o processo planejado, executado e
vericado se pode tomar aes corretivas para melhor-lo, caso
30 necessrio.

Um dos pontos mais criticados na norma ISO 9001 e em
outras que elas aumentam em muito a burocracia, pois exigem
GERENCIAMENTO DE PROJETOS DE TI
62


utput

Produto
Servio

u
e
i

procedimentos, maior controle de documentos e registros,
manuais, reunies auditorias, etc. Isto tudo tende a aumentar os
custos de produo de bens ou servios, por isso muitos veem
a norma como uma forma de aumentar os custos internos da
5 empresa.

bem verdade que se a norma no for implantada
corretamente ela pode prejudicar a empresa aumentando
os custos internos, porm se a implantao acontecer com
coerncia e os processos forem melhorados continuamente a
10 ISO aumenta a qualidade de entrega por um custo aceitvel.


Melhoria contnua do
sistema de gesto da
qualidade



R

C e
Gesto

l
q
de recursos

i
i

e
s
n i
t
t
Responsabilidade
da gesto


Medio, anlise,
melhoria


S

a C
t
l
i
s
f
a n

t

e
o Input

Realizao do produto
e

s
(e/ou servio)
o


Sistema de gesto da qualidade


Figura 31: Sistema de gesto da qualidade.


Fonte: <http://3.bp.blogspot.com/_-cxMcw9Ds9w/Sx9Bzgl7WQI/AAAAAAAAALE/
svumc7JFKcc/s1600-h/sgq.bmp>.


A norma possui basicamente oito princpios conforme
abaixo:


1. foco no cliente;

2. liderana entre objetivos comuns;

15 3. envolvimento de todos;
GERENCIAMENTO DE PROJETOS DE TI
63



4. abordagem de processos;

5. considerar o impacto de decises em outros processos;

6. melhoria contnua;

7. deciso baseada em dados;

5 8. benefcios mtuos entre clientes e fornecedores.

A norma ISO 9001 faz parte de uma famlia de normas ISO
9000, conforme explicado abaixo:

ISO 9000:1987: foi a primeira norma que tinha como base
a norma britnica BS 5750, sendo subdividida em trs
10 modelos:

ISO 9001:1987 Modelo de garantia da qualidade
para preto, desenvolvimento, produo, montagem e
prestadores de servio aplicava-se a organizaes
cujas atividades eram voltadas criao de novos
15
produtos.

ISO 9002:1987 Modelo de garantia da qualidade
para produo, montagem e prestao de servio
compreendia essencialmente o mesmo material da
anterior, sem abranger a criao de novos produtos.

20
ISO 9003:1987 Modelo de garantia da qualidade para
inspeo nal e teste abrangia apenas a inspeo
nal do produto e no se preocupava como o produto
era feito.

ISO 9000:1994: Apresentava os termos e denies da
25 norma ISO 9001:1994.

ISO 9001:1994: Enfatizava a qualidade atravs de aes
preventivas ao invs da validao apenas no produto
nal.
GERENCIAMENTO DE PROJETOS DE TI
64



ISO 9001:2000: Combina os trs padres 9001, 9002, e
9003 em um nico.

ISO 9000:2005: Sistema de Gesto da Qualidade,
Fundamentos e Vocabulrio.

5 ISO 9001:2008: Sistema de Gesto da Qualidade,
Requisitos.

ISO 9004:2009: Sistema de Gesto da Qualidade, Diretrizes
para Melhoria de Desempenho.


Um dos pontos mais importantes sem dvida a certicao.
10 Assim, para uma empresa receber o certicado ISSO deve passar
pela auditoria de uma empresa externa, que ir avaliar os
processos internos da empresa com a nalidade de comprovar
que todos so seguidos de forma correta.

4.1.2 NBR ISO 10006: Gesto da Qualidade Diretrizes
para a qualidade no gerenciamento de projetos

A NBR ISO 10006:2000 um padro escrito pela ISO com
15
diretrizes de qualidade para o gerenciamento de projeto.
Dene como os princpios e prticas da gesto de qualidade
relacionam-se com o gerenciamento de projetos.

A norma pode ser aplicada a projetos de complexidade
variada, ou seja, desde projetos pequenos a grandes, pequena
20 ou longa durao, independente do tipo de produto ou servio.
Os seguintes processos fazem parte da norma:

processo estratgico;

processos de gerenciamento de interdependncias;

processos relacionados ao escopo;

25
processos relacionados ao tempo;

processos relacionados ao custo;
GERENCIAMENTO DE PROJETOS DE TI
65



processos relacionados aos recursos;

processos relacionados ao pessoal;

processos relacionados comunicao;

processos relacionados ao risco;

5 processos relacionados aos suprimentos.

DICA: Uma boa fonte de leitura para comparao entre a
norma ISO e o PMBOOK poder ser acessada em: <http://www.
pmimg.org.br/artigos/Combinando10006EPMBOK.pdf>.


4.1.3 Maturidade em desenvolvimento de software
CMMI

CMMI, Capability Maturity Model Integration, um modelo, um
10 conjunto de prticas de gerenciamento e de melhoria de qualidade
a ser aplicado no processo de desenvolvimento de software.

Foi criado em 1987 por Watts Humphrey, na Universidade
de Carnegie Mellon, ligada ao Software Engineer Instute (SEI),
com a nalidade de garantir maturidade na capacidade de
15 desenvolvimento de software. O CMMI uma evoluo do CMM,
tambm conhecido como software CMM ou SW-CMM.

A verso atual do CMMI 1.2 apresenta trs modelos:

CMMI for Development (CMMI-DEV) publicada em agosto
de 2006: dirige-se ao processo de desenvolvimento de
20 produtos e servios;

CMMI for Acquisition (CMMI-ACQ) publicada em
novembro de 2007: dirige-se aos processos de aquisio e
terceirizao de bens e servios;

CMMI for Services (CMMI-SVC) publicada em fevereiro de
25
2009: dirige-se aos processos de empresas prestadoras de

servios.
GERENCIAMENTO DE PROJETOS DE TI
66



O modelo CMMI permite a representao da maturidade no
desenvolvimento de software atravs de cinco nveis, conforme
a gura abaixo:


5
Otimizao

Processo aperfeioado
continuamente
4
Gerenciando
Processo previsvel e controlado

3
Denido
Processo consistente e padronizado


2 Repetvel
Processo disciplinado

1 Inicial

Processo imprevisvel e sem controle



Figura 32: Nveis de maturidade CMMI


1. Inicial: neste nvel, os processos so improvisados e
5 geralmente no so seguidos. Estimativas so realizadas
sem nenhum planejamento. Compromissos de prazos e
custos no so cumpridos. Procedimentos e conhecimentos
pertencem s pessoas e no ao projeto.

2. Repetvel: aqui, as polticas e os procedimentos para
10 gerenciar o desenvolvimento de software esto denidos e
so obedecidos. O planejamento baseado em estimativas
e na experincia anterior de outros projetos. Os projetos
utilizam processos denidos, usados, disseminados,
documentados, medidos e scalizados com rotinas de
15 melhoria. Processos afetados so apenas os gerenciais.

3. Denido: os processos utilizados so estabelecidos e
padronizados em toda a organizao. Processos tcnicos
GERENCIAMENTO DE PROJETOS DE TI
67



passam a ser considerados ao lado dos processos
gerenciais.

4. Gerenciado: nesta fase so estabelecidas metas quantitativas
para os processos e produtos, medidas de qualidade e
5 produtividade so coletadas em todos os projetos. A gesto
realizada com base em informaes quantitativas.

5. Otimizado: nesta fase a organizao utiliza a melhoria
contnua do processo identicando pontos fracos e
defeitos atravs de aes preventivas.


4.1.4 Governana em TI

10 Nos dias atuais, todas as organizaes fazem uso da
Tecnologia da Informao para trabalhar os dados operacionais e
prover informaes gerenciais aos executivos da organizao. A
criao e a operao de uma infraestrutura de TI exigem um alto
investimento pela organizao e o gerenciamento deste ambiente
15 nem sempre fcil, podendo levar a organizao ao fracasso. Para
ajudar este cenrio surgiu a Governana de TI, uma subdisciplina
da Governana Corporativa focada no departamento do TI, em
sua performance e no gerenciamento de risco.


O grande interesse pela Governana em TI surgiu
20 principalmente pelas iniciativas de conformidade como a
Sarbanes Oxley, nos Estados Unidos, e a Basel II, na Europa, e
tambm por perceber que os projetos de TI podem facilmente
sair de controle e afetar profundamente as organizaes.


De forma geral, a Governana Corporativa tem o objetivo de
25 recuperar e garantir a conabilidade em uma determinada empresa
para os seus acionistas. Suas principais caractersticas so:


participao;

estado de direito;
GERENCIAMENTO DE PROJETOS DE TI
68



transparncia;

responsabilidade;

orientao por consenso;

igualdade e inclusividade;

5 efetividade e ecincia;

suporte auditoria.

Para suportar as implementaes da Governana em TI
existem alguns frameworks, conforme abaixo:

Control Objectives for Information and related Technology
10 (Cobit);

IT Infrastructure Library (ITIL);

ISO/IEC 27001 (ISO 27001);

IT Baseline Protection Catalogs;

Information Security Management Maturity Model ISM3;

15 AS8015-2005 Australian Standard for Corporate
Governance of Information and Communication
Technology;

ISO/IEC 38500:2008 Corporate governance of information
technology


4.1.5 CobiT

20
CobiT signica Control Objectives for Information and
related Technology, que um guia, formulado como framework
para gesto de TI, recomendado pelo ISACF (Information Systems
Audit and Control Foundation, <www.isaca.org>).


Foi publicado em 1996 com foco no controle e anlise de
25
sistemas da informao. Em sua segunda edio, em 1998, foi

GERENCIAMENTO DE PROJETOS DE TI
69



adicionado um guia prtico de implementao e execuo. A
verso atual 4.1 pode ser obtida no prprio site da ISACA e
introduziu as recomendaes de gerenciamento de ambiente de
TI dentro do modelo de governana.

5 O CobiT orientado ao negcio, fornece informaes para
gerenciar os processos alinhados aos objetivos de negcios,
ajuda a otimizar os investimentos de TI e fornece mtricas para
avaliao dos resultados.


Tem como objetivo auxiliar trs audincias distintas:

10 1. gerentes que precisam avaliar o risco e controlar os
investimentos em TI;


2. usurios que precisam ter garantias de que seus servios
de TI so bem gerenciados;


3. auditores que podem se apoiar nas recomendaes Cobit
15 para avaliar o nvel de gesto e aconselhar o controle
interno.


O CobiT organizado em quatro domnios de conhecimento,
conforme demonstrado na gura abaixo:
GERENCIAMENTO DE PROJETOS DE TI
70




Objetivos de negcios




Governana em TI





CobiT












Monitorao
Informao

Efetividade
Ecincia
Condencialidade
Integridade
Disponibilidade
Fidelidade
Conabilidade


Recursos de TI












Planejamento
e organizao







Entrega e
suporte
Pessoas
Sistemas de aplicao
Tecnologia
Infraestrutura
Dados


Aquisio e
implementao


Figura 33: Domnio do CobiT


De acordo com o professor Eduardo (Fagundes), as
caractersticas de cada domnio so:


Planejamento e organizao:

dene o plano estratgico de TI;
GERENCIAMENTO DE PROJETOS DE TI
71



dene a arquitetura da informao;

determina a direo tecnolgica;

dene a organizao de TI e seus relacionamentos;

gerencia os investimentos de TI;

5 gerencia a comunicao das direes de TI;

gerencia os recursos humanos;

assegura o alinhamento de TI com os requerimentos
externos;

avalia os riscos;

10
gerencia os projetos;

gerencia a qualidade.

Aquisio e implementao:

identica as solues de automao;

adquire e mantm os softwares;

15 adquire e mantm a infraestrutura tecnolgica;

desenvolve e mantm os procedimentos;

instala e certica softwares;

gerencia as mudanas.

Entrega e suporte:

20 dene e mantm os acordos de nveis de servios
(SLA);

gerencia os servios de terceiros;

gerencia a performance e capacidade do ambiente;

assegura a continuidade dos servios;

25 assegura a segurana dos servios;
identica e aloca custos;
GERENCIAMENTO DE PROJETOS DE TI
72



treina os usurios;

aconselha e assiste aos usurios;

gerencia a congurao;

gerencia os problemas e incidentes;

5 gerencia os dados;

gerencia a infraestrutura;

gerencia as operaes.

Monitorao:

monitora os processos;

10 analisa a adequao dos controles internos;

prov auditorias independentes;

prov segurana independente.

O principal benefcio do CobiT para as organizaes
possibilitar a compreenso de seu desempenho e medir o seu
15
progresso. Da mesma forma como a maturidade avaliada no
CMMI, o CobiT tambm utiliza um modelo semelhante, que pode
ser classicado em:

0. inexistente;

1. inicial / ad hoc;

20 2. repetitivo, mas intuitivo;

3. processos denidos;

4. processos gerenciveis e medidos;

5. processo otimizados.
GERENCIAMENTO DE PROJETOS DE TI
73



Desta forma, possvel avaliar onde a organizao est hoje
e aonde pretende chegar, traando assim os planos para atingir
seus objetivos.



5 CONCLUSO


15 Diante do que foi exposto nesta apostila, pode-se observar
o quanto importante o gerenciamento de projetos para uma
organizao. Existem diversas ferramentas, metodologias e
frameworks para ajudar na gesto, porm fundamental que os
gerentes de projeto faam o controle adequado dos requisitos e
20 da gesto de risco.

Pode-se observar que em todo projeto o passo mais
importante compreender o que o cliente realmente quer e
garantir que a entrega nal esteja de acordo com o solicitado.
Sabemos que muitas vezes o prprio cliente no sabe exatamente
25 o que deseja como resultado nal. Assim, cabe ao fornecedor do
servio identicar as possibilidades e demonstr-las para que o
cliente faa a escolha.


Devemos utilizar as informaes recebidas aqui para evitar a
todo custo que a gura abaixo acontea em um projeto.
GERENCIAMENTO DE PROJETOS DE TI
87


6. 0 Referncias bibliogrcas

Alencar, A. J.; Schimtz, E. A. Anlise de Risco em Gerncia
de Projetos. 1. ed. Rio de Janeiro, Rio de Janeiro: Brasport,
2006.


Barbi, F. C. (s.d.). Os 7 passos do gerenciamento de projetos.


Acesso em: 21 de 03 de 2010. Disponvel em: MSDN: <http://
www.microsoft.com/brasil/msdn/tecnologias/carreira/
gerencprojetos.mspx>.


Barnes, J. (2007). Implementing the IBM Rational Unified
Process and Solutions: A Guide to Improving Your


Software Development Capability and Maturity. IBM
Press.


Calder, A.; Watkins, S. (2008). IT Governanace: A Managers
Guide to Data Security and ISO27001/ISO 27002. 4. ed.
Kogan.
Como Tudo Funciona. (s.d.). Burj Dubai, o edifcio mais
alto do mundo. Acesso em 14 de 03 de 2010, disponvel
em Como Tudo Funciona: <http://viagem.hsw.uol.com.

br/burj-dubai.htm>.

Cooper, D., Grey, S., Raymond, G., & Walker, P. (2005). Project
Risk Management Guidelines: Managing Risk in Large Projects
and Complex Procurements. John Wiley & Sons.

Dinsmore, P. C., & Brewin, J. C. (2006). The AMA Handbook of
Project Management (2 ed.). Amacom.

Fagundes, E. M. (s.d.). COBIT. Acesso em 20 de 03 de 2010,
disponvel em Efagundes.com: http://www.efagundes.com/

Artigos/COBIT.htm

Gibbs, R. D. (2007). Project Management with the IBM
Rational Unied Process: Lessons From The Trenches. IBM
Press.

Hillson, D., & Simon, P. (2007). Practical Project Risk
Management: The ATOM Methodology. Management


GERENCIAMENTO DE PROJETOS DE TI
87


Microsoft. (s.d.). Um histrico rpido do gerenciamento de
projeto. Acesso em 14 de 03 de 2010, disponvel em Microsoft
Ofce Project: <http://ofce.microsoft.com/pt-br/project/

HA011353421046.aspx>.

Planner. (s.d.). Planner Gnome. Acesso em 21 de 03 de 2010,
disponvel em <live.gnome.org: http://live.gnome.org/Planner>.



PMI So Paulo. (s.d.). O Instituto. Acesso em 14 de 03 de 2010,

disponvel em Project Manager Institute So Paulo, Brasil
Chapter: <http://www.pmisp.org.br/instituto.asp>.

Portny, S. E. (2007). Project Management For Dummies (2 ed.).
John Wiley & Sons.


Posies e Formaes do Rugby . (s.d.). Acesso em 03 de 04 de
2010, disponvel em Rugby Mania: <http://www.rugbymania.



com.br/2009/rugby-posicoes08.asp>.
Project Control. (s.d.). Project Control. Acesso em 21 de 03 de
2010, disponvel em <http://www.projectcontrol.com.br/>.


Project Management Institute. (2008). A Guide to the Project
Management Body Of Knowledge (PMBOK Guide) (4 ed.).
Project Management Institute.

Takeuchi, H., & Nonaka, I. (1 de Janeiro de 1986). The New New

Product Development Game. Harvard Business Review Article ,
p. 10.


The Standish Group. (s.d.). Acesso em 14 de 03 de 2010,

disponvel em <http://www.standishgroup.com/>.

Trac. (s.d.). Trac. Acesso em 21 de 03 de 2010, disponvel em
Trac: <http://trac.edgewall.org/>.

Vinci, L. d. Monalisa.