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
Top Related