UNIVERSIDADE CANDIDO MENDES

PÓS-GRADUAÇÃO LATO SENSU

AVM FACULDADE INTEGRADA

Os Desafios da Gestão de Projetos em TI

Por: Bruno Ricardo da Silva

Orientador

Prof. Nelson Magalhães

Rio de Janeiro

2012

2

UNIVERSIDADE CANDIDO MENDES

PÓS-GRADUAÇÃO LATO SENSU

AVM FACULDADE INTEGRADA

Os Desafios da Gestão de Projetos em TI

Apresentação de monografia à AVM Faculdade

Integrada como requisito parcial para obtenção do

grau de especialista em Gestão de Projetos

Por: . Bruno Ricardo da Silva

3

AGRADECIMENTOS

Aos amigos de turma, de trabalho,

família, minha noiva Viviane e todos

aqueles que me deram todo o suporte

necessário durante esta caminhada.

4

DEDICATÓRIA

Onde estiver, espero que esteja feliz e

encontre seu caminho. Obrigado por tudo,

Mãe!

5

RESUMO

Esta monografia tem como objetivo navegar pelo conceito de gestão de

projetos e mostrar como as áreas de conhecimento de gestão de projetos

estão inseridas dentro de um projeto em TI e suas dificuldades, tendo como

objetivo principal descrever os desafios encarados e pontos de falha em

gestão de projetos para TI, como prevenir falhas e ilustrar utilização das

algumas das áreas de conhecimento e ferramentas de Gestão de projetos

inseridas em nesta.

6

METODOLOGIA

A metodologia utilizada é basicamente calcada sobre premissas

propostas pelo instituto americano Project Management Institute (PMI),

suportadas por nove áreas de conhecimento que são: escopo, tempo, custo,

risco, aquisições, qualidade, recursos humanos + ética, comunicação e

integração. O conhecimento destas áreas está documentado no Project

Management Body of Knowledge (PMBOK), onde estão detalhadamente

descritas técnicas.

O apoio em outras metodologias é fundamental para um projeto. Em TI,

são utilizadas outras metodologia de melhores práticas, como o CobiT (Control

Objectives for Information and related Technology) que é dirigido á gestão de

TI e também prover meios para otimizar os investimentos de TI. O COBIT

parte do princípio que deve haver alinhamento entre TI e os requisitos de

negócios da empresa, aumentando o valor dos produtos e serviços do negócio.

Existem outras metodologias utilizadas para gestão e projetos em TI, como

SCRUM (Desenvolvimento Software), Prince2 (Controle de Prazos em

projetos) e ITIL (Serviços em TI), que serão mencionadas dentro do trabalho

proposto.

7

SUMÁRIO

INTRODUÇÃO 08

CAPÍTULO I

Gerenciamento de Projetos 09

CAPÍTULO II

Gerencimento de Projetos em TI 15

CAPÍTULO III

O Passo a passo para um bom Gerenciamento de projetos em TI 16

CAPÍTULO IV

Fatores Criticos de sucesso em projetos de TI 31

CONCLUSÃO 34

GLOSSÁRIO 35

BIBLIOGRAFIA CONSULTADA 38

WEBGRAFIA CONSULTADA 38

INDICE DE FIGURAS 40

ANEXO 40

ÍNDICE 41

8

INTRODUÇÃO

Atualmente, a área de TI está expansão continua e é uma das mais

envolvidas em gestão de projetos em uma corporação. Tendo isto a

capacitação de profissional, condições de implementação, condução e uso

adequado de ferramentas de gestão e planejamento se fazem necessárias

para o bom andamento de um projeto. Como as demais áreas de uma

corporação, TI encontra muitos problemas no que diz respeito à gestão de

projetos. Então, o que fazer para otimizar a gestão de projetos em TI e qual o

caminho a seguir na utilização de recursos e ferramentas para isto? São

dúvidas que são comuns em corporações e ocasionam inúmeros problemas,

principalmente no que diz respeito à relação cliente x gerente de projeto. O

gerente de projeto deve possui uma alta expertise técnica no que diz respeito à

utilização de meios para condução de projeto, além de dinâmica e sabedoria

para tratar situações novas a todo o momento. Situações novas acarretam em

decisões e sendo assim, deve ter firmeza das decisões que foram provocadas

por alguma situação não prevista. Os grandes desafios em gerenciamento de

projeto de TI são: Levantamento de controle de escopo, cumprimento de

prazos, controle de custos, criticidade de riscos, comunicação entre partes

interessadas e equipe de projetos e nos próximos capítulos, estas serão

descritas de forma a dar suporte ao melhor gerenciamento em projetos em TI

baseado sempre no conjunto de conhecimento de melhores praticas de

gerenciamento de projetos assim descritos no PMBOK, que se propõe a

orientar as corporações na execução do gerenciamento de projetos.

9

CAPÍTULO I

Gerenciamento de Projetos

1.1 Definição

Existem varias definições para gerenciamento de projetos, porém todas

chegam a um meio comum: concretizar objetivos específicos. Segundo Turner,

a gestão de projetos é um processo pelo qual um projeto é direcionado a

fornecer um produto em uma conclusão. (TURNER, 2007).

Segundo ele, a gestão de projeto possui três dimensões: objetivos

(âmbito, organização, qualidade, custo, tempo); processo de gestão (planejar,

organizar, implementar, controlar); níveis (integrativo, estratégico, táctico).

Porém a refência mais utilizada e regulamentada é a definida pelo PMI (Project

Management Institute) que define gestão de projetos, como sendo o processo

através do qual se aplicam conhecimentos, capacidades, ferramentas e

técnicas às atividades do projeto de forma a satisfazer as necessidades e

expectativas dos diversos clientes e stakeholders, que são indivíduos

ativamente envolvidos no projeto ou o resultado deste lhe afetará diretamente,

podendo ser positivamente ou negativamente.

Uma visão altenativa é de que gerenciamento de projetos é uma

disciplina de definir, planejar e alcançar objetivos ao mesmo tempo em que se

realiza a otimização dos recursos em uso (tempo, dinheiro, pessoas, espaço,

entre outras).

1.2 Historia

O Gereciamento de projetos foi concebido através de vários campos de

aplicação, como construção civil, engenharia mecância, projetos militares,

entre outras. O americano Henry Gantt é conhedido como o pai do

gereciamento de projetos e de técnicas do planejamento e do controle, que é

conhecido também por levar seu nome no uso do grafico de barras como uma

10

ferramenta de gerência do projeto, chamado Grafico de Gantt. Outro influente

na historia do Gerenciamento de projetos é Frederick Wislow Tae e seu

trabalho é o precursor para muitas ferramentas atuais, como a WBS (Work

Breakdown Structure) ou EAP (Estrutura Analítica do Projeto).

O ano de 1950 ficou marcado como início da era moderna do

gerenciamento de projeto. Nos Estados Unidos, antes dos anos 50, os

projetos foram controlados basicamente se utilizando os graficos

desenvolvidos por Gantt, técnicas e ferramentas ainda não padronizadas. A

partir daí, dois modelos de gerenciamento de projeto especificos foram

desenvolvidos e espalharam-se rapidamente em muitas empresas:

1. Program Evaluation and Review Technique ou PERT, que

foi desenvolvido do programa do armamentod do submarino Polaris da

marinha dos Estados Unidos.

2. Critical Path Method (CPM), este desenvolvido em parceiria

entre a DuPont Corporation e Remington Rand Corporation com intuido

de gerenciar para projetos da manutenção de planta.

Em 1969, o Project Management Institute, o PMI, deu forma aos

anteriores para atender as necessidades da area do gerenciamento de projeto.

A premissa do PMI é que as ferramentas e as técnicas da gerência de projeto

podem ser aplicadas em areas diferentes, como em projetos para indústria de

software à indústria de construção. Em 1981, a alta diretoria do PMI autorizou

a disseminação do conhecimento que possuiam e assim, foi desenvolvido um

guia de projetos, o Project Management Body of Institute (PMBOK) contendo

os padrões e referencias das práticas utilizadas por um profissional de

gereciamento de projetos.

11

1.3 Abordagem Tradicional

Nas últimas décadas, varios tipo abordagens em projetos surgiram na

indústria em geral. Entre essas abordagens, a do PMBOK ganha destaque,

que é a referência de padrão para varias indústrias.

Na area de TI existem dois tipos de abordagens coutilizadas no

gerenciamento de projetos. As abordagens chamadas tradicionais mostram

uma sequência de passos a serem concluidos. Essas abordagens vão de

encontro a outro tipo, chamado desenvolvimento ágil de software, em que a

visão do projeto é como um conjunto de pequenas tarefas, ao contrario de um

processo completo.

Na abordagem tradicional dividida em cinco grupos de processos no

desenvolvimento do projeto:

1) Iniciação;

2) Planejamento;

3) Execução;

4) Monitoramento e controle;

5) Encerramento.

Nem todos os projetos seguem a risca os estagios acima, pois podem

estar encerradas antes do esperado, assim como alguns projetos podem

passar pelos estágios 2, 3 e 4 várias vezes.

Geralmente existem mais de uma alternativa para atender às mesmas

necessidades e as técnicas utilizadas para definir a solução final passam pelo

desenvolvimento de alternativas extremas (analise de risco). Um das

alternativas é a de baixo custo, que atende as demandas basicas para ser

funcional. Já outra é a que visa atender o máximo de exigências possiveis das

áreas envolvidas no escopo do projeto, o que resulta em um projeto de alto

12

custo. A partir de destas alternativas, pode se desenvolver uma solução

intermediária que atenda a maioria das exigências com um custo competitivo.

Outra areas de atuação utilizam variações desta. Por exemplo, na

indústria de construção civil, os projetos avançam como pré-planejamento para

areas de design conceitual, design esquemático, design de desenvolvimento,

construção de desenhos e administração de construção. Embora os termos

sejam diferentes de indústria para indústria, os processos seguem a mesma

linha para também resolução de problemas: identificar o problema, balancear

opções, escolher um caminho, implementar e avaliar.

Para manter o controle sobre o projeto do início ao fim, um gerente de

projetos utiliza várias técnicas, as quais se destacam:

• Planejamento de Projeto;

• Análise de valor agregado;

• Gerenciamento de riscos de projeto;

• Cronograma;

• Melhoria de processo.

1.4 Variáveis e Restrições

Alguns projetos necessitam ser executados e entregues sob

determinadas variáveis ou restrições. As variáveis principais também podem

ser denominadas como tradicionais. O gerenciamento de projetos baseia se

em tentar controlar três variáveis:

• Tempo;

• Custo;

• Escopo.

Na versão atual do PMBOK, as restrições do projeto são diretamente

relacionadas ao: Escopo, Qualidade, Cronograma, Orçamento, Recursos e

13

Riscos. Qualquer alteração em um desses itens certamente gerar restrições

em um ou mais dos demais itens.

As variações sobre estes três pontos (tempo, custo e escopo) é

chamada de triângulo da gerência de projeto, ou triângulo de restrições onde

cada lado representa uma variável. Um lado do triângulo não pode ser mudado

sem impactar os demais lados. Alguns autores entendem que a variável

qualidade está separada do escopo e é definida como uma quarta variável,

sendo considerada como parte do triângulo de restrição triplo expandido.

Outros defendem ainda, como sendo a terceira variável do triângulo de

restrições, classificando a qualidade e como uma das áreas do conhecimento -

gestão do âmbito (PMBOK).

Figura 1. Triangulo das restrições

Fonte: (http://www.gp3.com.br/index.php?/o-triangulo-das-restricoes-de-gerenciamento-de-projetos.html)

A restrição do tempo tem impacto continuo no prazo até o término do

projeto, assim como a de custo que informa o valor monetário incluído no

orçamento disponível para o projeto. Já a restrição do escopo designa o que

fazer para obtenção do resultado de fim do projeto, ou seja, o produto. Estas

três variáveis possuem competição entre elas: o escopo aumentado impacta

no aumento do tempo e o custo, uma restrição de tempo reduzido pode

ocasionar em custos aumentados e escopo reduzido e um orçamento limitado

gera aumento de tempo e escopo também reduzido.

Essas variáveis podem ser dadas por clientes externos ou internos. A

definição dos valores das variáveis remanescentes fica a cargo do gerente do

14

projeto, baseada em técnicas de estimativa. Os resultados finais devem ser

acordados em um processo de negociação entre a gerência do projeto e o

cliente. Geralmente, os valores em termos de tempo, custo, qualidade e

escopo são definidos por contrato.

A Seguir o detalhamento de cada umas destas variáveis:

Tempo

O tempo necessário para encerrar os processos de um projeto é

normalmente alterado quando se pretende reduzir o tempo de execução de

cada tarefa que está ligada à conclusão de cada processo. Ao executar tarefas

usando o gerenciamento de projeto, é necessário dividir o trabalho

corretamente em outras tarefas menores, tornando a definição das condições

de criticidade e de folgas mais simples.

Custo

O Custo de desenvolvimento de um projeto depende de diversas

premissas iniciais para desenvolver cada etapa dele tais como: taxas labor,

taxas materiais, gerência de risco, planta (edifícios, máquinas, entre outras),

equipamentos e lucro.

Escopo

São as premissas definidas para o resultado fim ou produto, ou seja, o

que será realizado dentro do projeto. A qualidade do produto final pode ser

tratada como um componente do escopo. Em geral a quantidade de tempo

utilizada em cada processo é fundamental para a qualidade total do projeto.

15

CAPÍTULO II

Gerenciamento de Projetos em TI

A Redução dos recursos humanos e a necessidade de especialização

têm direcionado empresas a recrutar no mercado profissionais temporários

apenas para um período de projetos específicos. Entender o gerenciamento de

projeto e seus processos tem se tornado essencial para as corporações na

medida em que a demanda de novos negócios vão sendo suportados por

projetos e existem know-how gerenciais que nem sempre estão localizadas

dentro das empresas

Um projeto nada mais é do que um empreendimento temporário, com

início e fim, objetivando criar e prover melhorias em um produto ou serviço. A

gerência de um projeto visa atuar no intuito de atingir objetivos determinados

dentro de premissas de qualidade determinados, seguindo um planejamento

de prazos (cronograma) e custos (orçamento). Sendo assim, definidas as

metas e restrições de recursos e tempo, o gerente do projeto deve garantir que

este alcance os objetivos definidos inicialmente.

A grande maioria das corporações está buscando uma estrutura de

projetos no seu dia-a-dia, principalmente em TI. Desde a idealização de um

novo software até a implantação dos procedimentos de Service Desk

(atendimento a usuários), Em vários setores, a abordagem de gerenciamento

de projetos está ganhando espaço por permitir uma otimização dos recursos

para alcançar objetivos bem definidos pela organização.

A demanda crescente pela padronização dos processos levou um

estimulo maior aos gestores e profissionais da área de TI a se especializarem

no uso da metodologia de Gestão de Projetos em seus negócios. Com esta

situação, a área de TI já é considerada a que mais aplica os conceitos de GP

em seus negócios (47%), atrás apenas de engenharia (66%), baseada em

pesquisa feita pelo IETEC (IETEC, Junho 2008)

16

CAPÍTULO III

O passo-a-passo para um bom gerenciamento de

projetos em TI

Em um projeto, o início se dá com a contratação de uma empresa para

tocar o projeto ou uma nomeação de colaboradores com experiência em

gerenciamento de projetos que integrarão a equipe de projeto. Em uma data

determinada é feito o chamado Kick-off do projeto, ou seja, inicia-se o projeto.

Esta data deve ser registrada com um documento denominado termo de

abertura do projeto. Em projetos de maior grandeza, o documento deve ser

assinado pelos patrocinadores (Sponsors) e pelo gerente do projeto e em

projetos menores, pode se restringir à um e-mail que o gerente envia aos

patrocinadores, copiando os envolvidos para conhecimento que naquela data

se iniciou o projeto e todos inclusos no comunicado estão envolvidos com a

sua execução.

Ao iniciar um projeto, são necessários alguns passos sejam seguidos

com utilização de metodologias para controle, alinhar comunicação, definir o

escopo do projeto com atenção e detalhar corretamente as atividades,

desenvolver cronograma e monitorar riscos. São as áreas de conhecimento em

gerenciamento de projetos, utilizadas como pilares de um projeto e é através

delas que o gerente tem um norte a seguir com o projeto.

A seguir é descrito alguns passos a serem tomado e com base nas áreas de

conhecimento de projeto:

17

3.1 Uso de Metodologia

Uma metodologia é um processo a seguir que dá maior controle sobre

os recursos que serão utilizados no projeto. Controlando melhor o processo a

equipe será mais eficiente, pois entregará o projeto com maior grau de acerto

em termos de prazos e custos. O bom uso de uma metodologia é importante

porque permite evitar práticas que levam ao insucesso e com isso reproduzir o

sucesso.

Em TI, A Microsoft utiliza o MSF (Microsoft Solutions Framework) no

desenvolvimento de produtos. Várias companias no segmento de software

optam pela utilização do CMM (Capability Maturity Model). A escolha da

metodologia deve ser tomada baseada nos seguintes fatores: as exigências do

segmento em que a empresa atual, mão-de-obra especializada e a cultura

organizacional necessária para implementação. Uma tendência mundial em TI

que tem ganhado espaço é exportação de software e para isso, muitas

empresas nacionais têm se alinhado com a utilização do CMM para obter

credibilidade a sua larga utilização em mercados dominados por indianos e

chineses, que possuem especialização neste padrão.

Em ultimo caso, uma metodologia é um conjunto de regras de como

conduzir um projeto com sucesso. Pode até não ter siglas bonitas, mas é

importante que a metodologia já tenha se mostrado eficiente dentro da sua

empresa, no caso, em situação similar à que você possui no seu projeto atual.

Um tipo de termo que ganha espaço e que está em evidência: a UML (Unified

Modeling Language) que, conforme o enunciado, não é uma metodologia, mas

sim uma linguagem, uma forma de documentação de projeto. Uma linguagem

de modelagem é uma notação e em geral feita com símbolos gráficos,

preparada para traduzir processos abstratos. A empresa responsável pela

criação do UML desenvolveu também uma metodologia chamada RUP

(Rational Unified Process).

18

Há melhores praticas que servem como suporte à gestão de TI e seus

serviços que são fundamentais em projetos da area, como a metodologia

COBIT (Control Objectives for Information and related Technology), que é um

guia de boas práticas apresentado como framework, direcionado para a gestão

de tecnologia de informação (TI).

O COBIT basicamente um framework baseado em processos de TI. E

que possui quatro domínios básicos:

• AI – Adquirir e Implementar

• DS – Entregar e Suportar

• ME – Monitorar e Avaliar

• PO – Planejar e Organizar

Deste quatro domínios, existem diversos processos que devem ser

alinhados às necessidades do negócio com a TI.

No domínio PO, o processo de ordem 10, ou PO10, é pura e

simplesmente ligado a gerenciamento de projetos. Neste processo, são

descritas melhores práticas a serem utilizadas para o gerenciamento de

projetos em TI, e algumas são baseadas em modelos e frameworks já

existentes, como o PMI, o Prince2, SCRUM, entre outros.

Segundo o COBIT, o processo PO10 tem a seguinte descrição:

”Estabelecer um programa e uma estrutura de gestão de projeto para o

gerenciamento de todos os projetos de TI. Essa estrutura deve assegurar a

correta priorização e a coordenação de todos os projetos. A estrutura deve

incluir um plano mestre, atribuição de recursos, definição dos resultados a

serem entregues, aprovação dos usuários, uma divisão por fases de entrega,

garantia da qualidade, um plano de teste formal e uma revisão pós-

implementação para assegurar a gestão de risco do projeto e a entrega de

valor para o negócio. Esta abordagem reduz o risco de custos inesperados e

de cancelamentos de projeto, aperfeiçoa a comunicação, melhora o

19

envolvimento das áreas de negócio e dos usuários finais, assegura o valor e a

qualidade dos resultados do projeto e maximiza a contribuição para os

programas de investimentos em TI”. (CoBIT 4.0, p69, 2007 IT Governance

Institute).

Já o ITIL é uma biblioteca de melhores práticas de gerenciamento de

Serviços de infraestrutura TI que pode suportar um projeto, podendo servir

como referência para a criação dos processos de uma empresa.

Os dois livros bases da biblioteca ITIL são: Service Support (Suporte

aos serviços) e Service Delivery (Entrega de Serviços) e abaixo basicamente o

framework de cada um.

O Service Support engloba os seguintes processos:

• Service Desk (Central de Serviços);

• Incident Management (Gerenciamento de Incidentes);

• Problem Management (Gerenciamento de Problemas);

• Configuration Management (Gerenciamento de Configuração);

• Change Management (Gerenciamento de Mudanças);

• Release Management (Gerenciamento de Liberações).

O Service Delivery, compreende os processos:

• Service Level Management (Gerenciamento de Nível de Serviço);

• Availability Management (Gerenciamento da Disponibilidade);

• Capacity Management (Gerenciamento da Capacidade);

• IT Service Continuity Management (Gerenciamento da

Continuidade dos Serviços em TI);

• Financial Management (Gerenciamento de Finanças)

20

3.2 Comunicação Efetiva

Quando existe falta de comunicação, os boatos e outras formas de

ruídos corporativos ganham força. Quando não existe versão oficial, são

disseminadas informações que podem abalar o espirito de equipe e levantar

suspeitas sem real credibilidade. O gerente de projeto deve blindar a equipe

contra este tipo de prática, conhecida por rádio peão, intensificando a

passagem de informações claras e confiáveis sobre o andamento do projeto.

A área de comunicação parte da premissa de que a diplomacia é

essencial. Quando ocorre um problema, o gerente de projetos não deve

apenas só falar sobre ele, mas também passar informações sobre como

trabalhar na solução, e não unicamente identificar que o problema existe.

Problemas sem direcionamento para solução provocam um desconforto na

equipe, que em sua grande maioria, é desnecessário. Relatórios sobre o

andamento do projeto ajudam muito no processo de comunicação, tornando o

processo mais objetivo.

Imagine as seguintes ações: um e-mail criticando um membro da equipe

por atraso em uma tarefa do projeto ou a mesma informação do e-mail inclusa

em um relatório em que a data de término da tarefa está em branco: Então

temos a mesma situação em ambo onde o indivíduo não fez a sua parte, mas

no caso do e-mail a pessoa envolvida pode ser reativa à afirmação. Já dentro

relatório, temos um dado objetivo, que salta aos olhos, mas que não gera ruído

ou ressentimento entre os membros.

21

3.3 Definindo Escopo do Projeto

Escopo do projeto é o trabalho realizado para obter um produto ou

serviço com características e recursos específicos. No primeiro momento,

deve-se delimitar o que deve e o que não deve ser feito. Esse processo nos faz

entender as reais necessidades e contornos do projeto e delimitar o que deve

ser feito e o que não deve ser no primeiro momento.

Iniciantes em gestão de projetos se perdem em discussões sobre

recursos do produto final que o tornariam perfeito. Existe o ditado que o ótimo

é inimigo do bom, ou seja: enquanto perseguimos o ótimo ficamos longe do

próximo, o bom, é que temos mais chance de conseguir atingir.

Para projetos em TI sendo, mais exato, em um projeto de software para

se perca em uma lista extensa de características da versão 1.0, a ideia básica

é listar o essencial, o que é também um problema dado à necessidade de

importância de o cliente ser diferente do gerente do projeto. Para resolução,

basta ser realista quanto ao tempo, que é curto e que se deve escolher

somente o que realmente é importante. A arte de se definir um escopo de

projeto passa por saber o que abandonar e o que reter do universo de

necessidades do cliente.

Definido um escopo do projeto, deve-se passar para a fase de

detalhamento das tarefas. Sendo assim, chegará ao WBS (Work Breakdown

Structure), que ilustrará os grupos de trabalho com tempo em dias ou horas de

trabalho. Pode se definir uma regra de atividade, dentro do grupo onde uma

atividade deve ocupar entre 4 e 80 horas, nem mais, nem menos.

22

Em paralelo a WBS, um orçamento deve ser feito baseado na utilização

de horas necessárias de cada profissional. Abaixo um modelo:

Profissional Tarefa 1

Tarefa 2

Tarefa 3

T.Total (h)

Custo/h Custo

Gerente de projeto 20 0 3 23 150,00 3.450,00

Líder de projeto 10 3 2 15 80,00 1.200,00

Analista Sênior 20 0 0 20 50,00 1.000,00

Programador 0 40 20 60 30,00 1.800,00

Testador/Documentador 0 20 30 50 15,00 750,00

Total - - - 168 - 8.200,00

Planilha 1. Exemplo de orçamento de recursos

Fonte – Site MSDN (http://www.microsoft.com/brasil/msdn/tecnologias/carreira/gerencprojetos.mspx)

Como base para o modelo acima, é necessário ter em mente o custo x

hora de cada profissional e tempo estimado que cada um irá gastar no período

do projeto. Os profissionais podem estar alocados em outros projetos enquanto

o programador está trabalhando em uma fase do projeto A, o gerente de

projeto pode estar realizando o planejamento do projeto B, retornando ao

projeto A no momento da entrega e aprovação.

As estimativas tornam-se mais precisas de acordo com o avanço do

detalhamento do projeto. No caso de uma estimativa inicial, é tolerável uma

variação de -25% a +75%. Já fase de planejamento, o orçamento tem variação

de -10% a +25%, lembrando que nessa fase o gerente de projeto já definiu os

grupos de trabalho e cada responsável pela tarefa. Na ultima estimativa, a

margem de erro é menor: de -5% a +10%. Aqui, o conhecimento do gerente de

projeto de situações anteriores fará diferença.

Um dos grandes segredos do gerenciamento de projetos é a proteção

ao escopo. Projetos mutáveis durante execução encontram dificuldades em

fechar o cronograma e ultrapassam o orçamento. O risco mais comum é o

23

chamado Scope Creep, que se trata do crescimento do escopo à medida que o

cliente vai entendendo suas necessidades e mudando os objetivos. Nesta

situação o gerente do projeto deve ter tranquilidade e analisar com cuidado

cada demanda: ao rejeitar um pedido, ele pode provocar um mal-estar junto ao

cliente, porém em caso de aceite pode comprometer o prazo e orçamento,

estes que não serão tão alterados após as exigências. Para evitar estouros de

tempo, devemos sempre contar com certa margem de manobra, mas nos

tempos atuais, em que eficiência é a palavra de ordem, não há muito tempo

disponível e os compromissos assumidos pelo gerente podem gerar demanda

extra para toda a equipe.

Em projetos de TI, o Scope Creep é uma muito comum e deve se tomar

algumas precauções:

1. Negociar a forma de remuneração: se irá ser fixa ou variável. No caso

de fixa, a responsabilidade e risco de mudanças é do gerente do

projeto, Sendo variável, o cliente assume todos os extras. Neste

segundo caso, o gerente do projeto deve cuidar para que o cliente seja

informado imediatamente dos novos custos. É valido possuir sempre um

adendo ao escopo inserindo sobre o que será feito, em quanto tempo e

custo. A execução é feita mediante autorização. Os gerentes financeiros

geralmente não estão envolvidos na reunião de aprovação de extras e

quase sempre alegam não haver recursos disponíveis, então sinalize

sempre das novas condições para evitar imprevistos no pagamento.

2. Documentar cuidadosamente o escopo do projeto. Este documento

descreve o que será feito, com que características e com que recursos.

É basicamente, é um contrato sem as cláusulas de rescisão e as

penalidades. O que ocorre na maioria das vezes quando não um escopo

é documentado corretamente um acordo entre as partes, porém com

uma imagem diferente do que é o produto final, aonde à medida que

este produto vai tomando forma e sendo entregue, o cliente enxergando

melhor o produto final e pode gerar decepções. Um cliente satisfeito

depende do que é dito e prometido no momento da pré-venda. É neste

24

momento que o gerente de projetos deve entrar em cena para

meticulosa, cuidadosa e disciplinadamente escrever tudo o que um

sistema deve ter e fazer. Este processo é denominado planejamento de

escopo. Esta tarefa pode delegada a um analista, mas o gerente deve

responder sempre. O Analista e o Gerente podem especificar toda a

interface dos usuários com o sistema: telas e relatórios. Depois de

documentar, deve haver uma aceitação por parte do cliente, de

assinado no final do documento em que todas as páginas serão

rubricadas para que esteja ciente do que será feito. As expectativas

devem estar alinhadas, de forma que, diante do produto final, o cliente

não possa se dizer decepcionado.

3. Definir prioridades. O gerente deve analisar minuciosamente quais são

os requisitos obrigatórios e os desejáveis pelo cliente, marcando cada

um de acordo com a sua prioridade. Esse processo blinda o projeto

quanto a arbitrar, o que é importante na posição do cliente. Existem

projetos em que os gerentes solicitam ao cliente para que defina o que

ele considera um fator de sucesso do projeto. Exemplificando: Em um

sistema que havia desperdício de 30% da matéria-prima, foi

considerado sucesso reduzir esta taxa para 15%. Mas este número

ainda pode ser alto, pois o cliente considera que uma redução de 50%

dos desperdícios já representaria benefícios que justificam o

investimento no projeto. Cabe o gerente negociar e definir a priori.

Em Resumo: Definição de escopo é ter visão do que fazer para atender uma

necessidade do cliente.

25

3.4 Conhecendo os envolvidos e Montagem de equipe

Todas as pessoas envolvidas no projeto são os stakeholders, que são

aqueles que precisam ter ciência de tudo que se passa no andamento. Este

grupo não inclui somente os membros da equipe, mas também clientes e

fornecedores envolvidos ao longo do projeto. Na empresa do cliente, haverá

uma pessoa que se destacará pela posição de patrocinadora (sponsor) do

projeto. Esta figura é que define condições para a aprovação do projeto,

mesmo que não seja usuário do produto final.

É fundamental que um gerente do projeto conheça os interesses de

todos os envolvidos visando evitar eventos como, por exemplo, membros que

não estejam dispostos a colaborar. Isto pode se tornar um problema e para

evitar maiores problemas, o gerente do projeto deve realizar a substituição do

membro.

Na definição do escopo, as habilidades necessárias vão ficando mais

claras durante o processo. Nesse momento é fundamental a formação de uma

equipe com competência diversificada, com experiência nas áreas de atuação

e experiência em projetos anteriores. Existem projetos em que onde existem

vários membros com conhecimento técnico, se destaca um líder de projeto que

é profissional com conhecimento técnico como os demais, porém com

capacidade de liderança em destaque que normalmente, é um profissional

sênior que possui credibilidade junto aos demais técnicos e com muita

experiência em projetos. Esta experiência pode economizar muito tempo e

dinheiro no projeto, pode assumir a liderança com voz ativa em certo nível e

fornecer insights que sobre assuntos que não são de domínio total.

26

3.5 Desenvolvendo um cronograma

Tendo definidas as tarefas do projeto a partir do escopo, deve-se

estimar tempo para essas. Para esta, o ideal é realizar essa estimativa junto ao

membro da equipe que irá realmente executará a tarefa que. Este membro

saberá qual o tempo necessário em uma tarefa em questão, assim que

definido se comprometerá com um prazo determinado para a sua execução.

Em condições de trabalho com consultores externos, o custo será relativo ao

tempo estimado da tarefa e da execução do projeto. Ao fixar e definir um

cronograma, o profissional irá definir o orçamento de sua parte.

A figura abaixo ilustram as atividades através do MS-Project, que

representam as linhas gerais de um projeto de software:

Figura 2. – Linhas Gerais de um projeto

Fonte – Site MSDN (http://www.microsoft.com/brasil/msdn/tecnologias/carreira/gerencprojetos.mspx)

Na lista de atividades é ilustrado exatamente o que deve ser feito.

As tarefas têm três pontos importantes: duração, interdependência e

responsável. A duração é um ponto importante, mas se as tarefas podem ser

realizadas em paralelo em tarefas que há duas figuras: o analista e o

programador, sendo assim a duração total do projeto encurtam.

27

Como possibilidade de trade-off entre tempo e recursos alocados,

alguns gerentes tomam o projeto como atrasado e então alocam mais recursos

(membros) para resolução, o que é um erro, pois o aumento de recursos pode

ocasionar em problemas de comunicação e gerar um atraso ainda maior no

projeto. A busca de membros pode se tornar útil quando não se possui mão-

de-obra especializada em um tema específico. Em uma situação normal de

planejamento bem realizado, a mão-de-obra já está no plano e será recrutada

em certo momento do projeto. O fato de aumentar a equipe para acelerar a

produção é incorreto e alguns gerentes de projeto medem seu poder pelo

tamanho da equipe que gerenciam. Nem sempre um projeto grande justifica

uma equipe grande.

Corrigir expectativas afoitas de colaboradores é uma das experiências

que o gerente de projetos deve trazer. Há quem estime 50 horas e possa vir a

cobrar por 120 horas necessárias para conclusão da tarefa, onde há um erro

de 140%.

Se o preço é fechado com o consultor, o risco fica todo com este, porém

sua disponibilidade e a qualidade do produto final podem sofrer reflexos em

decorrência da pressa. No caso da remuneração estar vinculada ao tempo de

serviço, o contratante preciso de um controle no mínimo confiável, como por

exemplo, um controle de horas diário e tarefas realizadas.

Caso haja no planejamento da semana há tarefas que não foram

realizadas, pode ser realizada uma reunião de avaliação e questionada porque

a atividade não seguiu o ritmo programado e quanto pode impactar na data

final de entrega. Estabelecer pontos de controle é fundamental, checkpoints,

que são datas que medem o andamento do projeto confrontando com o

cronograma previamente realizado. Nas datas definidas, pode ser feito apenas

verificação do progresso das atividades (milestones) ou pode haver entrega de

produtos ou subprodutos / entregáveis (deliverables) tais como versões piloto,

especificações, documentação, entre outras.

A verdade que em projetos de TI, a mão de obra nem sempre pode ser

substituída porque há muito conhecimento e estudo envolvidos, além gerar um

possível aumento de custo e tempo. Mas por isso mesmo, deve ser muito

28

cuidadosos na monitoração para saber em que momento ocorre o atraso do

projeto e como contornar este em um futuro próximo.

3.6 Monitorando Riscos

Com as tarefas definidas e divididas entre os membros, é essencial

mitigar riscos que podem influenciar de alguma forma o bom andamento do

projeto. Desenvolver uma lista com fatores de risco é o primeiro passo e em

seguida, um plano de ação de como lidar com eles. Lembrando que monitorar

é totalmente diferente de controlar riscos.

O monitoramento dos riscos consiste em acompanhar o status de cada

risco e as opções disponíveis pelo plano de ação definido para enfrentá-los,

em caso de problema real. A monitoração trabalha também com a

probabilidade do risco onde pode fornecer a visão de qual seria o seu impacto

no andamento do projeto e evita-lo. Em exemplo, Uma contratação de dois

profissionais para uma tarefa considerada critica pode parecer excessiva aos

olhos do cliente, mas o gerente do projeto tem a ciência de que se algo

acontecer nesta área do projeto pode impactar seriamente a sequência de

tarefas. Com esta situação, os membros passam a ser uma contingência /

backup do outro dentro da atividade.

29

Baseado nas linhas gerais de um projeto ilustrado na figura 2. ,

Usaremos como referência para chamar atenção para um recurso do MS

Project que tem como uma de suas finalidades, Identificar riscos, além de

tempo. Na figura 2. Abaixo, temos a tela do diagrama de Gantt que obtivemos

a partir da lista geral.

Figura 3. – Diagrama de Gantt

Fonte – Site MSDN (http://www.microsoft.com/brasil/msdn/tecnologias/carreira/gerencprojetos.mspx)

Percebemos na figura 2. Que há uma sequência de tarefas, que quando

alinhadas compõem o prazo de duração do projeto como um todo.

Em destaque em rosa e cinza é o que chamamos de caminho critico,

onde temos uma série de processos que dever possui uma gerência mais

efetiva uma vez que o atraso em alguma tarefa ocasionará em atraso do

projeto todo. Os riscos previstos nestas tarefas são os que devem ser tratados

de forma diferenciada e proativa.

Basicamente, o controle dos riscos é o processo de executar o plano de

ações e comunicar, divulgando seus relatórios de status de controle, podendo

talvez incluir mudanças no plano de riscos, e até nos planos do projeto. Todas

estas mudanças são relacionadas a recursos, funcionalidades ou cronograma.

30

3.7 Formalizando início e termino de projeto

O início do projeto é crucial. O patrocinador / sponsor irá iniciar o projeto

formalmente a todos os envolvidos, por meio documental, e é dado inicio ao

tempo de projeto. A divulgação do projeto em uma empresa é um fato de

extrema importância para que não haja resistência de setores. Sem um

documento comprobatório que o projeto começou, o gerente do projeto pode

encontrar resistências quanto a apoio. Além disso, da formalização, o

documento pode funcionar como decreto de uma autoridade da empresa: Sem

discussões, o projeto começou e os envolvidos devem participar.

Outro momento não menos importante é o do término do projeto. É

preciso formalizar o fim para que fique explicito para os envolvidos,

especialmente para o cliente, que o projeto está concluído e que novas

necessidades serão atendidas em caso de um novo projeto, então o ciclo de

conceber um projeto se inicia novamente. Com relação à manutenção e

suporte pós-projeto, ou seja, do sistema entregue, não é considerado um

projeto partindo do ponto inicial que se trata de um processo contínuo. O que

pode ocorrer é surgir um novo projeto ao longo da utilização do sistema, onde

são identificado pontos de melhoria que são cruciais para o sistema e

empresa.

No término do projeto, uma reunião de avaliação dos erros e acertos da

equipe é realizada. Chamadas de reuniões de lições aprendidas, elas servem

para se gerar uma lista de melhores práticas contribuindo para a formação de

uma base de conhecimento e lições quanto às piores práticas, atitudes e

decisões ruins e que devem ser evitadas em projetos futuros.

31

CAPÍTULO IV

Fatores críticos de sucesso em projetos de TI

O Standish Group, que estuda projetos de TI há 16 anos e já estudou mais

de 70 mil projeto realizados, classificou em uma pesquisa chamada CHAOS

Report o resultado dos projetos de TI em três situações:

Bem sucedido: Conclusão do projeto dentro do prazo e orçamento planejado,

com todos os recursos e resultados especificados desde o inicio do projeto.

Deficiente: O projeto é concluído e se encontra operacional, porém com

atrasos, custo acima do orçado ou recursos reduzidos e resultados aquém que

o especificado.

Falho: O projeto é cancelado antes de sua conclusão ou não é implementado.

A partir de um gráfico da própria pesquisa CHAOS, foram medidos

resultados de projetos de 1994 a 2008, conforme ilustrado na figura abaixo:

Figura 4. – Pesquisa CHAOS Report

Fonte – (http://blog.mhavila.com.br/2010/06/17/sucessos-e-falhas-em-projetos-de-ti)

32

Este estudo é considerado controverso por alguns autores no que diz

respeito a critérios, pois apontam que:

“Seus estudos apontam que as definições de sucesso e de desvio de

projetos têm quatro problemas principais: são ambíguas, unilaterais, pervertem

a prática de estimativa, e resultam em números pouco significativos”. (The Rise

and Fall of the Chaos Report Figures, por J. Laurenz Eveleens e Chris

Verhoef, Universidade Vrije de Amsterdam, 2009-09-04, publicado na IEEE

Software, vol. 27, num. 1, p 30-36, jan/fev 2010).

O Standish Group libera esta pesquisa de dois em dois anos desde

1994 e os resultados oferecem no mínimo um referencial histórico para

analises sobre sucesso em projetos.

Existe uma grande correlação entre o PMBOK e entre a efetividade de

execução de projeto. Quanto maior a disseminação dos conceitos e práticas de

planejamento e controle no gerenciamento de projetos, com a participação de

organizações profissionais como o próprio PMI, maior será o sucesso dos

projetos e haverá reduções consideráveis de fracasso. Entre 1994 e 1996, o

sucesso em projetos medido através de uma pesquisa CHAOS Report teve um

considerável salto positivo, de 16% para 27%. A partir de 1996, a taxa de

sucessos cresceu em menos escala, porém até 2002 a taxa de fracassos

reduziu consideravelmente, de 40% chegando a 15%.

A Variação de sucessos e fracassos desde 2002 tem como base o

aumento de abrangência, complexidade e criticidade dos projetos de TI, assim

com ao desenvolvimento de tecnologias e estas sendo atualizadas em alta

intensidade, aumentando a necessidade de readaptação dos processos de

trabalho e das estratégias institucionais.

33

O Standish Group também aponta um conjunto mais consistente de

fatores críticos de sucesso para projetos de TI:

• Disseminação sobre envolvimento e este deve ser positiva.

• Suporte da alta direção.

• Plano de negócios bem definidos.

• Maturidade entre as partes envolvidas (stakeholders), mantendo

sobre controle as chamadas Cinco Sinas Mortais no gerenciamento de

projetos, que são: ambição excessiva, arrogância, ignorância, abstinência e

fraudulência.

• Obter valor para o negócio de forma otimizada, minimizando

riscos.

• Processos ágeis, com desenvolvimento iterativo.

• Conhecimento em gerenciamento de projetos com referencia no

Guia PMBOK e demais órgãos de gestão de projetos.

• Equipe altamente capacitada, sabendo lidar como adquirir,

gerenciar e controlar os recursos certos no momento certo e inteligência nos

momentos de turnover.

34

CONCLUSÃO

A constante variação de escopo, metas e objetivo de um projeto por

conta de novas necessidades das partes interessadas somados a mudanças

de diretrizes e critérios provêm a cada projeto com uma particularidade única,

mas sempre com a questão de tempo abordada em sua maioria.

Para cada projeto, uma situação diferente ou já vivenciada

anteriormente e o gerente do projeto deve estar preparado para as variáveis

que podem aparecer do inicio ao fim do projeto. Em TI, a intensidade de

variações é bem mais frequente pelos fatores de evolução tecnológica,

expertise técnica e gestão de tempo e pessoas.

O perfil do profissional de TI não sinaliza para um líder nato e tão pouco

aquele que posso características de bom relacionamento com membros de

uma equipe de projeto, porém isto tem mudado bastante. Como a área de TI é

constantemente envolvida em projetos, o profissional que não se adequa as

condições sugeridas dentro da metodologia sugerida pelo PMBOK pode ser

caracterizar com um grande ofensor dentro do projeto e isso tem levado cada

vez mais profissionais a se especializarem dentro das metodologias de projeto,

não somente PMBOK, mas como as outras demais. Existem também outros

pontos para que se atinja uma excelência na aplicação de gerenciamento de

projetos em uma corporação: pleno conhecimento do plano estratégico da

empresa e a metodologia ideal para aplicação de técnicas.

Neste documento foi dado como sugestões um passo-a-passo em

situações de gerenciamento de projetos em TI e qual o melhor caminho

recomendo assim como informações sobre ferramentas de gerenciamento

inseridas nesta mesma. Os cenários para TI podem variar de corporação para

corporação de acordo com o plano estratégico de negócios dela, tendo o apoio

necessário ou não em projetos e cabe a equipe de projetos junto com o

gerente justificarem e ganhar a importância e valor agregado que um projeto

de TI pode trazer, quando na maioria das vezes não é visto como um retorno

imediato e produto visível.

35

GLOSSÁRIO

C

Checkpoints – Pontos de checagem / revisão em um projeto

CMM – ou Capability Maturity Model, é uma metodologia de melhores praticas

para diagnostico e avaliação de maturidade em desenvolvimento de Software

de uma empresa.

Control Objectives for Information and related Technology – Ou CoBIT,

Metodologia utilizada em Governança de TI

CHAOS Report - Pesquisa realizada pelo Standish Group, onde trás a

evolução / redução de riscos de projetos em TI através dos anos.

D

Deliverables – No sentido puro da palavra os entregáveis do projeto

I

Information Tecnology Infrastructure Library - Ou ITIL, Metodologia de

melhores práticas a serem aplicadas em infraestrutura, operação e

manutenção de serviços de TI.

M

Milestones – Pontos chaves do projeto

MSF – ou Microsoft Solutions Framework é uma metodologia desenvolvida

pela própria Microsoft para melhores praticas no desenvolvimento de software

MS Project – Software desenvolvido pela Microsoft voltado para gerenciamento

de projetos.

36

P

Prince2 - Ou PRojects IN Controlled Enviroments, é uma metodologia de

gerenciamento de projetos também voltada para controle e organização de

projetos.

Project Management Institute – Ou PMI, Instituto de Gerenciamento de

projetos, localizado nos EUA.

Project Management Body of Knowledge- Ou PMBOK, Documento contendo

todas as informações e técnicas de gerenciamento de projetos.

PERT – ou Program Evaluation and Review Technique, é uma técnica de

planejamento baseada em probabilidade de tempo e usa três tipos de

durações (otimista mais provável e pessimista).

R

RUP – ou Rational Unified Process, é um processo que aborta orientação a

objetos dentro da engenharia de software em sua concepção.

S

SCRUM – Metodologia de desenvolvimento Iterativo e Incremental para

gerenciamento de projetos em desenvolvimento ágil de software

Scope Creep – Termo sobre crescimento do escopo do projeto de acordo com

a demanda do cliente

Sponsors – chamados de patrocinadores do projeto, geralmente entram com

os recursos financeiros do projeto.

Standish Group – Organização responsável por realizar pesquisas sobre riscos

em projetos de TI.

Stakeholders – pessoas envolvidas e interessadas em um projeto.

37

T

Turnover – Rotatividade de pessoal dentro da empresa.

U

UML - ou Unified Modeling Language, é uma linguagem de programação que

permite os desenvolvedores acompanhar seus trabalhos em diagramas

padronizados.

W

WBS – Ou Work Breakdown Structure, ilustra as atividades e tarefas definidas

por meio de organograma.

.

38

BIBLIOGRAFIA CONSULTADA

Berkun, Scott. A arte de gerenciamento de projetos, 1ª. Ed, São Paulo:

ARTMED, 2008.

Cleland, David; Ireland, Lewis. Gerência de Projetos, Rio de Janeiro:

Reichaman & Affonso, 2002.

ISACA. Cobit, IT Governance Institute, Versão 4.0, © 2007.

TURNER, J. R. Gower - The handbook of project based management. 4th

Edition. Ed. McGraw-Hill, 2007.

TURNER, J. R. ; MÜLLER, R. The project manager's leadership style as a

success factor on projects: a literature review. Project Management Journal,

New Jersey, v. 36, n. 2, p. 49-61, Junho 2005.

WEBGRAFIA CONSULTADA

A

A justificativa da gestão de projetos de TI para as organizações.

http://www.administradores.com.br/informe-se/producao-academica/a-justificativa-da-gestao-de-projetos-de-t-i-para-as-organizacoes/439

Acesso 16/11/2011 às 18h15min

C

WebGrafia – Como escolher metodologias em TI

http://boaspraticasdeti.blogspot.com/2009/11/fases-de-um-projeto-metodologia-parte-2.html

Acesso 04/12/11 às 18h30min

39

G

WebGrafia - Gestão de Projetos de Tecnologia da Informação – Diferencial Competitivo.

http://ogerente.com.br/rede/projetos/tecnologia-da-informacao

Acesso 15/11/2011 às 17h33min

WebGrafia – Gerenciamento de serviços em TI

http://alexkobayashi.wordpress.com/tag/itil/

Acesso 08/01/2012 às 14h35min Gestão de Projetos e TI: Garantia de bons resultados.

http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/590 Acesso 14/09/2011 às 09h56min

O

O Triangulo das Restrições em Gerenciamento de Projetos

http://www.gp3.com.br/index.php?/o-triangulo-das-restricoes-de-gerenciamento-de-projetos.html Acesso em 05/01/2012 às 16h15min

Os sete passos do gerenciamento de projetos

http://www.microsoft.com/brasil/msdn/tecnologias/carreira/gerencprojetos.mspx Acesso 15/11/2011 às 16h58min

R

Resumo do CoBiT e seus conceitos fundamentais

http://www.joww.net/blog/2010/10/18/resumo-do-cobit-e-seus-conceitos-

fundamentais

Acesso em 04/01/2012 às 20h30min

S

Sucesso e falhas em projetos de TI.

http://blog.mhavila.com.br/2010/06/17/sucessos-e-falhas-em-projetos-de-ti

Acesso 20/11/2011 às 22h10min

40

ÍNDICE DE FIGURAS

Figura 1. Triangulo das Restrições 13

Figura 2. Linhas Gerais de Projeto 25

Figura 3. Diagrama de Gantt 28

Figura 4. Pesquisa CHAOS Report 30

ANEXO

Planilha 1. Exemplo de orçamento de Recursos 21

41

ÍNDICE

FOLHA DE ROSTO 2

AGRADECIMENTO 3

DEDICATÓRIA 4

RESUMO 5

METODOLOGIA 6

SUMÁRIO 7

INTRODUÇÃO 8

CAPÍTULO I

GERENCIAMENTO DE PROJETOS 11

1.1 - Definição 09 1.2 - História 09 1.3 - Abordagem Tradicional 11 1.4 - Variáveis e Restrições 12

CAPÍTULO II

GERENCIAMENTO DE PROJETOS EM TI 15

CAPITULO III

O PASSO A PASSO PARA UM BOM

GERENCIAMENTO DE PROJETOS EM TI 16

3.1 - Uso da metodologia 17 3.2 - Comunicação Efetiva 20 3.3 - Definindo Escopo do Projeto 21 3.4 - Conhecendo os envolvidos e montagem de equipe 25 3.5 - Desenvolvendo um cronograma 26 3.6 - Monitorando Riscos 28 3.7 - Formalizando Inicio e Término do Projeto 30

CAPITULO III

FATORES CRITICOS DE SUCESSO

EM PROJETOS DE TI 31

CONCLUSÃO 34

GLOSSÁRIO 35

42

BIBLIOGRAFIA CONSULTADA 38

WEBGRAFIA CONSULTADA 38

INDICE DE FIGURAS 40

ANEXO 40

ÍNDICE 41