Unidade IV - Governança e Projetos em TI

Prévia do material em texto

Gestão de Tecnologia 
da Informação 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Responsável pelo Conteúdo: 
Prof. Ms. Artur Marques 
 
Revisão Textual: 
Profa. Ms. Magnólia Gonçalves Mangolini 
Governança e Projetos em TI 
Material teórico 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Governança e Projetos em TI 
Nessa unidade falaremos, de forma introdutória, da 
importância do gerenciamento de projetos na área de TI, 
focada no framework, proposto pelo PMBOK®, não 
concentrado em desenvolvimento de sistemas. Para isso, 
podemos utilizar métodos ágeis e alguns outros associados a 
CMMI e ao próprio PMBOK®, estamos nos referindo 
especificamente em infraestrutura e outros tipos de projetos 
que ocorrem em Gestão de Tecnologia de Informação. 
Também abordaremos o framework ITIL, muito utilizado em 
TI para realizar a gestão de serviços visando à prestação de 
um serviço melhor ao usuário e atendimento das áreas da 
empresa que precisam de suporte. Atuam também em 
incidentes e problemas. Trata-se, atualmente, do framework 
mais utilizado para este fim, no Brasil e no mundo. 
Veremos introdutoriamente os livros que cuidam de gestão de 
suporte e serviços. 
Enfatizo a leitura do material deste módulo de forma atenta e, 
após isso, você precisa realizar os exercícios propostos. 
 
Atenção 
Para um bom aproveitamento do curso, leia o material teórico atentamente antes de realizar 
as atividades. É importante também respeitar os prazos estabelecidos no cronograma. 
 
 
 
 
 
 
Silva Filho (2006) versa que, até certo ponto, é natural àqueles que desenvolvem 
novos sistemas iniciarem suas atividades de desenvolvimento antes mesmo que eles entendam 
o que tem de ser feito, ou seja, antes mesmo que saiba qual é o problema a ser solucionado. 
O resultado desse tipo de atitude é e tem sido o insucesso de projetos. 
Para trabalharmos e gerirmos um projeto, devemos trabalhar longamente no 
entendimento do trabalho a ser feito e nas entregas esperadas, caso contrário, não saberemos 
onde temos que chegar e isso é o grande causador de fracassos e problemas com clientes 
internos e externos a organização e também é a causa mais comum da inserção de erros logo 
cedo no desenvolvimento que custarão muito caro quando forem descobertos. Isso acontece 
infelizmente porque há pouca preocupação do profissional de tecnologia da informação com a 
Gestão, principalmente dos insumos humanos e materiais necessários para o correto 
aproveitamento e cumprimento dos objetivos do projeto. Problemas culturais e baixa 
capacitação dos colaboradores são outros problemas que recrudescem o resultado ruim dos 
projetos em tecnologia da informação. 
Renner (2008), citando Ricardo Viana Vargas do PMI board, diz que apesar do Brasil 
ter um número limitado de profissionais certificados em práticas de gerenciamento de projetos, 
cerca de cinco mil, e da América Latina responder por apenas 4% do total mundial, a 
realidade é muito diferente em outras partes do globo. 
Grande parte dos profissionais certificados no Brasil atua preponderantemente na área 
de tecnologia da informação, setor que tem maior carência e necessidade desse tipo de 
profissional devido à complexidade dos projetos que são realizados e a criticidade empresarial 
que representam nos dias de hoje. 
As organizações no mercado globalizado em que vivemos realizam seus objetivos 
estratégicos através de projetos. Neles estão contidas as doses de inovação investidas para 
produzir produtos e serviços diferenciados que garantirão a sobrevivência das empresas na 
economia moderna e hiper competitiva a qual vivemos. 
Vamos conhecer um pouco sobre as melhores práticas que têm transformado em 
sucesso os projetos das organizações em todo o mundo. 
 
 
 
 
Contextualização 
 
 
 
 
 
Fundamentos de Gestão de Projetos 
 
O conceito moderno sobre gerência de projetos nasceu nos Estados Unidos, no final da 
década de 50 e início da década de 60, motivado, entre outras coisas, pelo projeto Apollo que 
levaria o homem à Lua. Todavia, as aplicações iniciais das melhores práticas foram aplicadas 
para se realizar a análise de sistemas computacionais e a implementação de empreendimentos 
físicos, como construções complexas e bens de consumo. 
A gestão de projetos fornece conceitos e melhores práticas para que sejam enfrentadas 
as mudanças e riscos impostos pelo dia a dia da globalização e a necessidade de lançar 
produtos e serviços em tempos cada vez menores, com cada vez mais qualidade e valor 
agregado. Além disso, a gestão de projetos oferece ferramentas e técnicas para lidar com essas 
mudanças. O responsável pela execução e gerenciamento dessas mudanças se chama gerente 
de projetos. 
De acordo com o PMBOK (2008) “um projeto é um empreendimento único que deve 
apresentar um começo e um fim claramente definidos e que, conduzido por pessoas, possa 
atingir seus objetivos respeitando os parâmetros de prazo, custo e qualidade”. 
O que caracteriza de forma mais marcante um projeto são as categorias de entregas 
que ele pode proporcionar, como por exemplo: 
 
• Produtos: produto ou objeto produzido, quantificável, podendo ser final ou 
intermediário. 
• Serviços: são itens de capacidade, funções de negócio para produção, 
armazenagem ou logística, desenhos ou melhorias em processos, inovação em uma 
abordagem de sistemas, entre outros. 
• Resultados: relatórios, pareceres, documentos, resultados finais. Por exemplo, 
criação de algo inovador que gere uma documentação de patente, um projeto de 
pesquisa exploratória que desenvolve ciência. 
 
Subprojetos: em vários casos um projeto precisa ser dividido em partes devido a sua 
grande complexidade ou característica de produção, isso auxilia em seu gerenciamento e 
controle. Essas partes, que foram divididas, chamamos de subprojetos. Elas são muito 
específicas e podem ser feitas por terceiros ou por equipes dedicadas. O mais importante é 
que o subprojeto tratado isoladamente não faz sentido, ele precisa estar agregado ao projeto 
principal. Imagine que a arquitetura e modelagem do banco de dados para uma aplicação 
específica em tempo real seja tratada como subprojeto, ela não tem sentido em ser 
desenvolvida se não houver o projeto de software que tratará estas informações em tempo 
Material Teórico 
 
 
real, ou seja, não há outra utilidade para essa modelagem que não seja servir esse software, 
ela não serve para outro software. 
 
• Programas: usamos esse termo para designar quando vários projetos estão 
concentrados em um conjunto de melhoramentos e táticas comuns. O mais 
importante é que eles podem ter vida própria, além do projeto principal. Por 
exemplo, vamos fazer um avião, uma das partes é a turbina, ela faz parte do 
programa do avião, ou seja, a turbina pode ser desenvolvida para esse avião que 
será construído, mas pode ser usada por outros projetos de aviões diferentes que 
possam utilizar o mesmo propulsor. 
 
Gerenciamento de projetos: conforme definição do PMBOK (2008) é a aplicação de 
conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto, cuja finalidade é 
atender aos seus requisitos. Isso inclui, mas não se esgota em: 
• Identificar as necessidades do projeto; 
• Estabelecer objetivos claros, mensuráveis e alcançáveis; 
• Balancear, distribuir e resolver demandas conflitantes que envolvam entre outras 
áreas de conhecimento: riscos, qualidade, escopo, tempo, comunicação e custo; 
• Adaptar as especificações e abordagens, dos diferentes planos, preocupações e 
expectativas dos stakeholders (partes interessadas) que na versão 5 do PMBOK é 
uma área de conhecimento nova. 
 
Conforme Schmitz(2005, 16), as áreas de conhecimento do PMBOK são 9 e possuem 
os seguintes propósitos: 
• Escopo: A Gerência de Escopo assegura que o projeto inclua todo o trabalho necessário, 
e tão somente o necessário, para complementar de forma bem sucedida o mesmo. Define 
e controla o que está e o que não está incluído no projeto. A principal ferramenta é a 
Estrutura Analítica do Projeto – EAP (em inglês, WBS – Work Breakdown Structure), que 
identifica e decompõe os principais elementos do projeto. 
• Tempo: Seus processos consideram a definição de atividades e seu sequenciamento 
(identificação de relacionamentos de dependência entre elas), estimativas de recursos e 
duração, desenvolvimento do cronograma e seu controle. Os processos da gerência de 
tempo são executados em paralelo com a gerência de custos, uma vez que a duração de 
uma atividade depende diretamente da quantidade de recursos alocados para a mesma. 
• Custo: Contempla os custos dos recursos necessários a implantação das atividades. Ela 
inclui os processos necessários para assegurar que o projeto será concluído dentro do 
orçamento aprovado. Seus processos são a estimativa e orçamento dos custos e seu 
controle. As principais técnicas e ferramentas utilizadas são: avaliação especializada de 
consultores, estimativas por analogia de outros projetos, estimativas por desagregação de 
custos (botton-up) ou modelos paramétricos. 
 
 
• Qualidade: Garantir que o projeto irá satisfazer as necessidades para as quais ele foi 
empreendido. A preocupação com qualidade deve ser estendida também para os 
fornecedores de insumos do projeto, devendo ficar claro que as referências de qualidade 
da organização devem ser seguidas nos projetos. 
• Risco: propõe a identificação, análise e resposta aos riscos do projeto, considerando 
riscos internos e externos. Os processos contemplam a identificação, qualificação e 
quantificação dos riscos, desenvolvimento e controle de respostas, e monitoramento. A 
abordagem geralmente utilizada é a análise dos resultados que devem ser evitados e a 
monitoração de suas causas por meio do estabelecimento de gatilhos de aviso. 
• Comunicação: Garantir a geração, coleta, distribuição, armazenamento, recuperação e 
destinação final das informações sobre o projeto de forma oportuna e adequada. Previne 
interpretações errôneas e garante que a informação correta esteja disponível para quem 
dela necessite. 
• RH: Contempla os processos requeridos para possibilitar o uso mais efetivo das pessoas 
envolvidas no projeto. Os principais tópicos a serem destacados são: liderança, 
negociação, comunicação, delegação, motivação, formação de equipes, gerência de 
conflitos, treinamento, avaliação de desempenho, recrutamento e manutenção das 
relações de trabalho. 
• Aquisição: Inclui os processos necessários para a obtenção de bens e serviços externos a 
organização executora, para a realização do trabalho. Possui as seguintes necessidades: 
preparação das aquisições e contratações, obtenção de propostas, seleção de 
fornecedores, administração e encerramento dos contratos. 
• Integração: Compreende a coordenação entre os diversos elementos do projeto, através 
de processos, ferramentas e técnicas. É executada durante todo o projeto, paralelamente 
as demais gerências, integrando seus resultados no Plano do Projeto. 
 
Grupo de processos: trata-se dos macroprocessos existentes durante o ciclo de vida de 
um projeto e serve para demonstrar, determinar e atuar sobre documentos, relatórios, 
atuações, papéis e fases esperadas para saber como está à situação do projeto e quais esforços 
estão consumindo os recursos. Essas fases são: 
• Iniciação: Determina a existência do projeto, são documentos e atividades de 
autorização e início. Por exemplo: contrato assinado, designação do gerente de 
projeto, termo de abertura do projeto. 
• Planejamento: Cria e depura os objetivos do projeto, cria documentos 
estruturados de planejamento de ação necessários para atingir as metas e o escopo 
do projeto. 
• Execução: trata da junção de recursos humanos e materiais para a execução do 
projeto, é o fazer, conforme estabelecido na fase de planejamento. 
• Monitoramento e controle: estabelece medidas para controle de desempenho e 
previsão identificando variações contra o plano estabelecido para que possam ser 
tomadas medidas proativas e reativas sob as situações encontradas. 
• Encerramento: constitui os elementos de finalização do projeto, entre outros a 
parte operacional, entregas, termos de aceite, termos de homologação e também a 
 
 
parte administrativa, como por exemplo, ordem de emissão de nota fiscal final, 
encerramento de contrato, entre outros. 
 
Figura 1: Grupo de Processos do PMBOK para Gestão de Processos. 
Fonte: http://professorprojeto.blogspot.com.br/2011/04/mapas-mentais-pmbok.html 
 
Então podemos perceber que cabe ao GP e a equipe determinar quais processos são 
os adequados e o grau de exigibilidade de cada processo para cada empresa e para cada 
projeto em específico. 
 
Escopo 
Conforme Ricardi (2005), Escopo possui os seguintes componentes: 
• Do produto: é aquilo que vai ser entregue como resultado do projeto, ou seja, um 
produto, serviço ou qualquer outro resultado específico. 
• Do projeto: é o conjunto das atividades que precisam ser realizadas para entregar 
o escopo do produto. 
• Requisitos: representam as características de algo que será entregue ou 
executado. Portanto podemos ter, em uma visão macro, requisitos de produto e 
requisitos de projeto. Uma das melhores formas de detalhar o escopo do projeto e 
 
 
do produto é através do detalhamento de requisitos associados. Através deles você 
consegue aumentar a precisão em documentar as necessidades e desejos dos 
envolvidos (partes interessadas) no projeto. Devem atender as seguintes 
características: 
o Necessário: ele é essencial para o bom funcionamento da entrega ou do 
projeto. Se não estiver presente, caracteriza uma deficiência; 
o Completo: não exige complementos para ser atingido ou atendido, ou então 
está relacionado a outros requisitos que o complementam e esta relação está 
explícita e é de conhecimento e aprovada por todos quem interessa; 
o Consistente: não contradiz outros requisitos ou outros aspectos relacionados 
ao projeto; 
o Não ambíguo: evita interpretação ambígua; 
o Conciso: define uma única coisa que deve ser feita e só a coisa que deve ser 
feita; 
o Isento de implementação: define o que deve ser feito ou atendido, e não 
como ocorrerá; 
o Factível: é passível de ser atingido durante a execução do projeto, por um 
custo dentro dos limites orçados, no prazo necessário e com os recursos 
disponíveis; 
o Verificável: pode ser quantificado de forma a ter o seu atendimento verificado 
através de testes ou inspeções. 
• Componentes: um documento de escopo bem definido deverá conter em sua 
composição pelo menos: 
o Critérios de aceitação 
o Objetivos 
o Premissas 
o Restrições 
Sua constituição é feita dos seguintes processos e atividades: 
 
Entradas 
• Termo de abertura do projeto 
Fornece a base para iniciar o detalhamento dos requisitos, pois contém a descrição 
do produto e alguns requisitos em alto nível. 
• Registro das partes interessadas 
Serve de referência para identificar quais as partes interessadas que poderão 
fornecer detalhes e definição a respeito dos requisitos necessários. 
 
 
 
 
 
 
Ferramentas e Técnicas 
 
• Entrevistas 
Utiliza conversas diretas com as partes interessadas, individualmente, no formato 
de perguntas e respostas, que deverão ser registradas e aprovadas pelos 
entrevistados. 
• Dinâmicas de grupo 
Reúnem especialistas e partes interessadas pré-qualificadas, com o objetivo de 
levantar expectativas e atitudes relacionadas ao escopo do produto e/ou ao escopodo projeto. 
• Oficinas 
Reúnem partes interessadas de diversas áreas e/ou funções, com o objetivo de 
definir rapidamente requisitos que atendam a todos, reconciliando diferenças entre 
os diversos requisitos associados. Técnica recomendada para levantamento de 
funcionalidades complexas e que envolvem muitos interessados. Exemplos: JAD 
(Joint Application Design) e QFD (Desdobramento da Função de Qualidade). 
• Técnicas de criatividade em grupo 
 Brainstorming 
A criatividade não é repreendida, e todos podem sugerir e opinar a respeito. 
 
 Técnica de grupo nominal 
Amplia a técnica de Brainstorming incluindo um processo de votação. 
 
 A técnica DELPHI 
São elaborados questionários que são submetidos, de forma anônima, a 
especialista no assunto. Estes deverão responder a um facilitador que repetirá o 
envio aos envolvidos, em ciclos de perguntas e respostas, até coletar todos os 
requisitos necessários. 
 
 Mapas mentais 
Diagramas com estrutura de itens e subitens, assuntos e descrições, que 
denotam linha de raciocínio semelhante ao cérebro humano. 
 
 Diagrama de afinidade 
Organiza grande quantidade de ideias agrupando para revisão e análise. 
• Técnicas de tomada de decisão em grupo 
Avalia múltiplas alternativas com o objetivo de resolver ações futuras. Gera, 
classifica e prioriza os requisitos do produto. Inclui os seguintes métodos: 
 Unanimidade 
 Maioria 
 
 
 Pluralidade 
 Ditatura 
 
• Questionários e pesquisas 
Utilizados quando existe um universo muito grande de candidatos a entrevistas, e 
não há tempo hábil para conversas individuais. 
 
• Observações 
Acompanhamento e observação dos profissionais em seu ambiente de trabalho, 
onde a probabilidade de esquecimento de requisitos importantes é minimizada, e o 
entendimento das necessidades fica facilitado. 
• Protótipos 
Validação de modelo funcional do produto anterior à sua construção. Permite ao 
cliente visualizar e em algumas situações manipular o produto de forma simulada. 
 
Saídas 
• Documentação dos requisitos 
Algumas organizações têm ferramentas específicas que permitem a documentação 
e o gerenciamento dos requisitos do projeto e do produto. Descreve como os 
requisitos individuais irão atender às necessidades de negócio do projeto, e pode 
ser apresentada em forma de listas categorizadas, priorizadas e associadas a outras 
informações importantes e necessárias para o projeto. 
 
• Plano de gerenciamento dos requisitos 
Define como os requisitos serão levantados, analisados, documentados e 
gerenciados durante todo o ciclo de vida do projeto. Não menospreze a 
importância deste plano, por ele ser um plano auxiliar. Sem uma definição 
consistente relacionada a este assunto, o projeto pode tomar um rumo de 
descontrole e falta de objetividade, e as consequências serão imprevisíveis. 
 
• Matriz de rastreabilidade dos requisitos 
Associa os requisitos aos objetivos de negócio e aos objetivos do projeto. Ainda, 
consolida os requisitos criando referência com outros requisitos e com as entregas 
do projeto. 
 
• EAP: trata-se de Estrutura hierárquica que decompõe as entregas do projeto e os 
pacotes de trabalho associados. Será utilizada como base para estimar e controlar 
escopo, custos e cronograma. 
 
 
 
• Dicionário da EAP: Fornece o detalhamento dos componentes da EAP. Segundo o 
Guia PMBOK, poderá conter as seguintes informações (inclua ou retire aquelas que 
considerar necessário): 
 
o Código de identificador da conta 
o Descrição do trabalho necessário 
o Organização ou pessoa responsável pela execução 
o Lista de marcos do cronograma 
o Atividades do cronograma associadas 
o Recursos necessários 
o Estimativa de custos 
o Requisitos de qualidade 
o Critérios de aceitação (da entrega, que pode conter os critérios dos requisitos 
associados, e mais algum que tenha a ver diretamente com a entrega. Exemplo: 
esta entrega deverá ser validada pelo Diretor Fulano de Tal) 
o Referência técnica 
o Informações do contrato 
o 
 
• Linha de base do escopo: Componente do plano de gerenciamento do projeto é 
composta pelos documentos: 
o Declaração de escopo do projeto 
o EAP 
o Dicionário da EAP 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2: exemplo EAP para um sistema de informação 
Fonte: http://www.gtics.com.br/wa_files/GRUPO-04_EAP_v1_3.png 
 
 
 
Id. Pacote de Trabalho Descrição 
1.1 
Análise da situação atual Levantamentos dos pontos críticos e oportunidades de melhoria, 
suas causas e consequências. Este pacote realizou o estudo 
necessário para a definição da estratégia a ser seguida: terceirizar ou 
desenvolver solução própria 
1.2 
Alocação da equipe Designação de funcionários para o projeto. 
 
Definição da função de cada membro e disponibilidade de tempo 
exigida. 
 
 
Definição de cada membro da equipe, por pacote de trabalho. 
1.3 
Elaboração do Plano de 
Projeto 
Define como o projeto será executado, quais são os recursos, 
financeiros e humanos alocados. 
2.1 
Estudo e mapeamento 
do fluxo de trabalho 
para procedimento de 
leilão eletrônico 
Analisar e realizar um mapeamento de um fluxo de trabalho padrão 
para leilão eletrônico a todos os cartórios. 
Figura 3: exemplo de um dicionário de EAP 
Fonte: http://desenv.tjms.jus.br/confluence/pages/viewpage.action?pageId=5505070 
 
Tempo 
Para o PMBOK® (2008:112), “o Gerenciamento do Tempo do Projeto inclui os 
processos necessários para gerenciar o término pontual do projeto”. 
Marques et ali (2011) apontam e comentam os seguintes processo e atividades 
necessários para a gestão do tempo no projeto, incluindo o diagrama de rede e o cálculo DO 
CAMINHO Crítico envolvendo a técnica CPM – Critical Path Method a saber: 
• Definir as atividades: Trata-se da identificação das ações que precisam ser feitas 
para produzir as entregas do projeto. Para tanto precisamos, após identificá-las, 
criar a EAP – Estrutura Analítica do Projeto - que serve para identificar as entregas 
no nível mais baixo da estrutura, a qual chamamos de pacote de trabalho. Uma 
vez levantada junto às áreas uma lista de atividades que serão realizadas, passamos 
a criação da EAP e inserimos seus tempos. Porém, para iniciarmos, precisamos 
conhecer algumas técnicas para definir essas atividades. 
• Decomposição: trata-se de subdividirmos os pacotes de trabalho em atividades 
que, de acordo com o PMBOK®, são mais gerenciáveis, de forma que o trabalho e 
 
 
as entregas estejam definidos até o nível de pacote de trabalho. Este nível é o mais 
baixo na EAP antes do Deliverable e é onde o custo e o cronograma podem ter 
uma estimativa mais confiável. Decompor envolve algumas atividades como: 
o Identificar as entregas relacionadas à estruturação e organização da EAP. 
o Quebrar os níveis mais elevados da EAP ampliando a granularidade, ou seja, 
detalhando para níveis mais baixos. 
o Atribuir os códigos de identificação (taxonomia) aos itens da EAP. 
 
• Lista das atividades: segundo as melhores práticas do PMBOK® (2009:118), a 
lista das atividades é uma lista abrangente que inclui todas as atividades 
necessárias no projeto. Inclui o identificador e uma descrição do escopo do 
trabalho de cada atividade em detalhe suficiente para assegurar que os membros 
da equipe entendam qual trabalho precisa ser executado. 
 
• Lista dos marcos: o marcos é datas chave no projeto e servem para designar ou 
identificar um evento significativo e importante no projeto. Podendo ser uma 
entrega, uma reunião ou uma homologação, início ou encerramento. 
 
• Sequenciar as atividades: Considera que as principais atividadesde um projeto 
devem ser executadas levando-se em consideração a ordem e os desdobramentos 
das atividades que compõem os pacotes de trabalho e as entregas da EAP. Para o 
PMBOK® (2009:119), sequenciar as atividades “é processo de identificação e 
documentação dos relacionamentos entre as atividades do projeto”. Essas são 
sequenciadas usando relações lógicas (atividade predecessora e sucessora). 
Sequenciamento permite que todas as partes interessadas no projeto possam 
visualizar o trabalho a se realizar até a finalização do projeto. O Gerente de 
Projetos deverá possuir em suas mãos como entradas para a execução das 
atividades de sequenciamento: 
o Lista das atividades; 
o Atributos das atividades; 
o Lista dos marcos; 
o Declaração do escopo do projeto; 
o Ativos de processos organizacionais. 
• Método do diagrama de precedência (MDP): constrói o diagrama de rede do 
projeto através do uso de diversos nós que objetivam representar as atividades, e 
setas são utilizadas para que os nós fiquem ligados, mostrando suas dependências. 
Esta técnica é chamada de Atividade nos Nós, a maioria dos sistemas que apoiam 
o gerenciamento de projetos é baseada nela. O PMBOK® (2009:120) determina 
quatro tipos de dependências: 
o Término para Início (TI) - o início da atividade sucessora depende do 
término da atividade predecessora. 
o Término para Término (TT) - o término da atividade sucessora depende do 
término da atividade predecessora. 
 
 
o Início para Início (II) - o início da atividade sucessora depende do início da 
atividade predecessora. 
o Início para Término (IT) - o término da atividade sucessora depende do 
início da atividade predecessora. 
 
Figura 4: Exemplo de diagrama de precedência MDP 
Fonte: http://arquivos.unama.br 
 
Existem três tipos de determinação que podemos utilizar: 
o Dependências obrigatórias: conforme o PMBOK® (2008:120), são aquelas 
exigidas contratualmente ou inerentes à natureza do trabalho. A equipe do projeto 
define quais dependências são obrigatórias durante o processo de sequenciamento 
das atividades. Geralmente envolvem limitações físicas, tais como num projeto de 
construção onde é impossível erguer a superestrutura antes que a fundação tenha 
sido concluída, ou num projeto de componentes eletrônicos, onde um protótipo 
tem que ser construído antes de ser testado. 
o Dependências arbitradas: normalmente são estabelecidas baseadas no 
conhecimento das melhores práticas numa área de aplicação específica ou em 
algum aspecto particular do projeto onde uma sequência específica é desejada, 
mesmo que haja outras sequências possíveis ou aceitáveis. Existe a necessidade de 
documentação dessa dependência para evitar problemas de comunicação e para 
justificativa do caminho escolhido. 
o Dependências externas: o gerente do projeto ou sua equipe definem quais 
dependências são externas durante o processo de sequenciamento das atividades. 
Isso envolve uma relação entre as atividades do projeto e as não pertencentes ao 
mesmo. Aplicação de antecipações e esperas: PMBOK® (2009) determina que 
uma antecipação permita um aceleramento da atividade sucessora. Por exemplo, 
num projeto para construir um novo edifício de escritórios, o paisagismo poderia 
ser agendado para começar duas semanas antes do término agendado dos itens da 
lista. Isso seria mostrado como um término para início com uma antecipação de 
duas semanas. Uma espera direciona um retardo na atividade sucessora. Por 
exemplo, uma equipe de redação técnica pode iniciar a edição do rascunho de um 
grande documento quinze dias após ter começado a escrevê-lo. Isso poderia ser 
mostrado como um início para início com uma espera de quinze dias. O uso de 
antecipações e esperas não deve substituir a lógica de desenvolvimento do 
cronograma. As atividades e suas premissas relacionadas devem ser 
documentadas. Uma antecipação permite um aceleramento da atividade sucessora. 
 
 
 
• Modelos de diagrama de rede de cronograma: são utilizados para agilizar a 
preparação da rede de atividades e normalmente estão em repositórios de 
conhecimento nas organizações para esta finalidade. Podem conter todo projeto ou 
partes ou até mesmo fragmentos. Segundo o PMBOK® (2009:121): (...) os 
modelos de sub-redes são especialmente úteis quando um projeto inclui várias 
entregas idênticas ou quase idênticas, tais como andares num alto prédio de 
escritórios, testes clínicos num projeto de pesquisa farmacêutico, módulos de 
programas de codificação num projeto de software, ou a fase inicial de um projeto 
de desenvolvimento. 
• Estimar os Recursos da Atividade: As melhores práticas do PMBOK® rezam 
que, para estimar os recursos de uma atividade envolvemos os tipos e quantidades 
de material, pessoas, equipamentos ou suprimentos que serão necessários para 
realizar cada atividade da EAP. Estimar os recursos para uma atividade está 
intimamente ligado com o processo de estimativa de custos, sendo que podemos 
nos apropriar das mesmas técnicas que utilizamos nessa área da gestão de projetos. 
Dois exemplos práticos impostos pelo PMBOK® (2009:122) demonstra o grande 
grau de sinergia entre esses processos: 
o Uma equipe de um projeto de construção precisará estar familiarizada com as 
legislações de construção locais. Geralmente, tal conhecimento está facilmente 
disponível em fornecedores locais. Contudo, se o serviço de mão de obra local 
carece de experiência em técnicas de construção incomuns ou especializadas, 
o custo adicional de um consultor pode ser a maneira mais efetiva de assegurar 
o conhecimento das legislações de construção locais. 
o Uma equipe de planejamento automotivo precisará estar familiarizada com as 
mais recentes técnicas de montagem automatizada. O conhecimento 
necessário pode ser obtido através da contratação de um consultor, do envio 
de um projetista a um seminário de robótica, ou da inclusão de alguém da 
produção como um membro da equipe do projeto. 
• Estimar as Durações da Atividade: segundo o PMBOK® (2008), é o processo de 
estimativa do número de períodos de trabalho que serão necessários para terminar 
as atividades específicas com os recursos estimados. 
o A estimativa das durações das atividades utiliza informações sobre as atividades 
do escopo do projeto, tipos de recursos necessários, quantidades estimadas de 
recursos e calendários de recursos. As entradas para as estimativas de duração 
da atividade se originam da pessoa ou grupo na equipe do projeto que está 
mais familiarizado com a natureza do trabalho na atividade específica. A 
estimativa da duração é elaborada progressivamente e o processo considera a 
qualidade e a disponibilidade dos dados de entrada (PMBOK®, 2009:125). 
Estimar a duração de uma atividade requer que a quantidade do esforço e recursos 
necessários sejam aplicados para finalizar a atividade. Dessa forma, estes elementos são 
utilizados para gerar o número de mês/dias/horas de trabalhos necessários para a finalização 
 
 
da atividade. A duração decorre do esforço requerido para completar o trabalho relativo a 
uma atividade do projeto, e ajustar esse esforço levando em conta com os seguintes fatores: 
o A quantidade de recursos que irão realizar o trabalho e o grau de eficiência desses 
recursos. 
o O calendário de disponibilidade dos recursos (isto é se eles estão disponíveis a 100% 
ou numa outra qualquer percentagem inferior de tempo). 
o Os períodos específicos de inatividade (fins de semana, feriados e férias contratuais). 
o Número normal de horas diárias de trabalho. 
Para estimarmos a duração, podemos utilizar um mapeamento mediante o uso de um 
fluxo como nos exemplos abaixo: 
 
Figura 5: Fluxo para concluirmos a atividade para estabelecer a duração das atividades no projeto. 
Fonte: http://ricardosatin.blogspot.com/2009/12/estimativa-de-duracao-de-atividades.html• Desenvolver o Cronograma: Conforme o PMBOK® (2009:129), desenvolver o 
cronograma é o 
 
 “processo de análise de sequências das atividades, suas durações, recursos 
necessários e restrições do cronograma visando criar o cronograma do projeto. 
A entrada das atividades, durações e recursos na ferramenta de elaboração de 
cronograma gera um cronograma com datas planejadas para completar as 
atividades do projeto” (PMBOK®. 2009. P.129). 
 
 
 
Importante citar no processo de construção do cronograma, tratar-se de um elemento 
dinâmico e ativo de forma que a sua revisão e a manutenção são necessárias para mantê-lo 
em concordância à realidade e deve ser executada durante todo o projeto à medida que o 
trabalho avança, pois o plano de gerenciamento muda e a natureza dos eventos de riscos, 
custos e recursos humanos evolui. Para podermos desenvolver o cronograma, precisamos 
estar munidos dos seguintes documentos de projeto, que chamaremos aqui de entradas do 
processo Desenvolver o Cronograma: 
o Lista das atividades 
o Atributos das atividades 
o Diagramas de rede do cronograma do projeto 
o Requisitos dos recursos da atividade 
o Calendários dos recursos 
o Estimativas da duração da atividade 
o Declaração do escopo do projeto 
o Fatores ambientais da empresa 
o Ativos de processos organizacionais. 
 
• Análise da rede do cronograma: os diagramas de rede são amostras 
esquemáticas das atividades do cronograma do projeto e as suas relações lógicas, 
também chamadas de dependências. 
• Método do caminho crítico: calcula as datas hipotéticas de início e término 
mais cedo e início e término mais tarde, em todas as atividades, sem considerar 
quaisquer limitações de recursos, executando uma análise dos caminhos de ida e 
de volta através da rede do cronograma. De acordo com o PMBOK® (2009), as 
datas resultantes de início e término mais cedo e início e término mais tarde não 
são necessariamente o cronograma do projeto, mas sim uma indicação dos 
períodos de tempo dentro dos quais a atividade poderia ser agendada, dadas as 
durações do projeto, relações lógicas, antecipações, esperas e outras restrições 
conhecidas. 
O PMBOK® (2009:132) determina que os caminhos críticos tenham uma folga total 
igual à zero ou negativa e as atividades do cronograma que estão no caminho crítico são 
chamadas ― atividades críticas. Um caminho crítico é normalmente caracterizado por uma 
folga total igual à zero no caminho crítico. Redes podem ter múltiplos caminhos quase críticos. 
Ajustes às durações da atividade, relações lógicas, antecipações e esperas e outras restrições 
do cronograma podem ser necessários para produzir caminhos com folga total zero ou 
negativa. Uma vez que a folga total para um caminho da rede tenha sido calculada, a folga 
livre, isto é, a quantidade de tempo que uma atividade pode ser atrasada sem atrasar a data 
de início mais cedo de qualquer atividade imediatamente sucessora dentro do caminho crítico, 
pode também ser determinada. 
 
 
 
Figura 06: Caminho crítico em um projeto (em vermelho) 
Fonte: http://teccrono.com.br/plan-desenvolvimento.html 
• Compressão do Cronograma: conforme PMBOK® (2009), serve para encurtar 
o cronograma do projeto sem mudar o escopo do mesmo, para respeitar as 
restrições do cronograma, datas impostas ou outros objetivos do cronograma, as 
técnicas de compressão do cronograma incluem: 
o Compressão. Exemplos de compressão poderiam incluir a aprovação de horas 
extras, recursos adicionais ou o pagamento para a aceleração da entrega das 
atividades no caminho crítico. A compressão funciona somente para as 
atividades onde recursos adicionais encurtarão a sua duração. A compressão 
nem sempre produz uma alternativa viável e pode resultar num maior risco 
e/ou custo. 
o Paralelismo. Uma técnica de compressão do cronograma na qual fases ou 
atividades normalmente executadas em sequência são executadas em 
paralelo. Um exemplo é a construção da fundação de um prédio antes que 
todos os desenhos arquitetônicos tenham sido terminados. O paralelismo 
pode resultar na repetição de trabalho e aumento de risco. O paralelismo 
funciona somente se as atividades podem ser sobrepostas para encurtar a 
duração. 
 
Figura 06: Compressão 
Fonte: http://teccrono.com.br/ 
 
 
 
 
Figura 07: Paralelismo 
Fonte: http://teccrono.com.br/ 
 
• Saídas do processo para criar o cronograma: 
o Cronograma do projeto: o cronograma do projeto inclui pelo menos uma data 
de início e de término planejadas para cada atividade. 
o Gráficos de marcos: esses gráficos assemelham-se aos gráficos de barras, porém 
identificam somente o início ou término agendado para as entregas mais 
importantes e interfaces externas chaves. 
o Gráfico de barras: esses gráficos, onde as barras representam as atividades, 
mostra as datas de início e término da atividade, assim como as durações 
esperadas. 
o Diagramas de rede do cronograma do projeto: esses diagramas, com 
informações sobre as datas das atividades, normalmente mostra tanto a lógica 
da rede do projeto como suas atividades do seu caminho crítico. 
o Linha de base do cronograma: uma linha de base do cronograma é uma versão 
específica do cronograma do projeto desenvolvido a partir da análise de rede 
do mesmo. 
o Dados do cronograma: os dados de apoio do cronograma para compor o 
cronograma do projeto incluem pelo menos os marcos, as atividades, os 
atributos das atividades e a documentação de todas as premissas e restrições 
identificadas. 
o Por último, o PMBOK® (2009:139) depois consultar o especialista, reza que 
para manter os documentos em dia é preciso. 
o Requisitos dos recursos das atividades. O nivelamento dos recursos pode ter um 
efeito significativo nas estimativas preliminares dos tipos e quantidades de 
recursos necessários. Se a análise do nivelamento de recursos muda os 
requisitos dos recursos do projeto, então os mesmos são atualizados. 
o Atributos das atividades. Os atributos das atividades são atualizados para incluir 
quaisquer requisitos de recursos revisados ou quaisquer outras revisões 
geradas pelo processo Desenvolver o Cronograma. 
o Calendário. O calendário para cada projeto pode usar diferentes unidades como 
base para Desenvolver o Cronograma do projeto. 
 
 
o Registro dos riscos. O registro dos riscos pode precisar ser atualizado para refletir 
oportunidades ou ameaças percebidas através das premissas de agendamento. 
 
• Controlar o Cronograma: E o processo de monitoramento do andamento do 
projeto para atualização do seu progresso e gerenciamento das mudanças feitas na 
linha de base do cronograma. Conforme o PMBOK® (2009: 136), o controle do 
cronograma está relacionado a: 
o Determinação da situação atual do cronograma do projeto; 
o Influência nos fatores que criam mudanças no cronograma; 
o Determinação de que o cronograma do projeto mudou; 
o Gerenciamento das mudanças reais conforme ocorrem. 
 
 
Fundamentos de Governança com ITIL 
 
Como estamos constantemente frisando em nossos estudos, a TI tem ganhado peso e 
importância nas organizações, seus desafios também aumentaram em proporção semelhante; 
abaixo citamos alguns: 
• Ajustar os serviços de TI com as necessidades e metas atuais e futuras dos negócios 
da empresa. 
• Aumento da complexidade no ambiente de TI. 
• Os negócios estão cada vez mais dependentes de TI. 
• Minimização de riscos e custos. 
• Melhores justificativas para o ROI - retorno sobre os investimentos em TI. 
• Mais leis e regulamentos com exigência de conformidade imediata. 
• Zelo sobre a segurança das Informações. 
Os negócios empresariais, buscam melhorias e otimizações com maior frequência e 
possuem metas audaciosas para reduzir riscos e custos, por isso foram pensados diversos 
frameworks com a intenção de melhorar processos e práticas.Vamos falar especificamente de 
ITIL - IT Infrastructure Lybrary, composta pelas melhores práticas para Gerenciamento de 
Serviços de TI. Foi introduzida pelo Governo Britânico em 1980 e se tornou padrão no 
mercado em 1990. É uma biblioteca composta de 5 livros. Não é uma metodologia, mas sim 
um conjunto de melhores práticas adotadas por diversas empresas em várias partes do 
mundo. 
Estas melhores práticas pretendem: 
• Inspirar a melhoria dos processos de TI; 
 
 
• Estabelecer metas e nortear o futuro mostrando que outras empresas já lograram 
êxito; 
• Orientar e sugerir para que servem os processos e práticas; 
• Propor e motivas a adoção destes processos e práticas. 
Conforme Pinheiro (2006,13), os livros que compõem a biblioteca de melhores práticas 
ITIL são: 
• Suporte a Serviços: descreve os processos associados ao suporte do dia-a-dia e 
atividades de manutenção associadas com a provisão de Serviços de TI. 
• Entrega de Serviços: cobre os processos necessários para o planejamento e 
entrega de Serviços de TI com qualidade e se preocupa ao longo do tempo com o 
aperfeiçoamento desta qualidade. 
• ICT - Gerenciamento da Infraestrutura: cobre todos os aspectos do 
Gerenciamento da Infraestrutura como a identificação dos requisitos do negócio, 
testes, instalação, entrega, e otimização das operações normais dos componentes 
que fazem parte dos Serviços de TI. 
• Planejamento para Implementação do Gerenciamento de Serviços: 
examina questões e tarefas envolvidas no planejamento, implementação e 
aperfeiçoamento dos processos do Gerenciamento de Serviços dentro de uma 
organização. Também foca em questões relacionadas à Cultura e Mudança 
Organizacional. 
• Gerenciamento de Aplicações: descreve como gerenciar as aplicações a partir 
das necessidades iniciais dos negócios, passando por todos os estágios do ciclo de 
vida de uma aplicação, incluindo até a sua saída do ambiente de produção 
(quando o sistema é aposentado). Este processo dá ênfase em assegurar que os 
projetos de TI e as estratégias estejam corretamente alinhados com o ciclo de vida 
da aplicação, assegurando que o negócio consiga obter o retorno do valor 
investido. 
• Perspectiva de Negócio: fornece um conselho e guia para ajudar o pessoal de 
TI a entender como eles podem contribuir para os objetivos do negócio e como 
suas funções e serviços podem estar mais bem alinhados e aproveitados para 
maximizar sua contribuição para a organização. 
• Gerenciamento da Segurança: detalha o processo de planejamento e 
gerenciamento da segurança da informação e Serviços de TI, incluindo todos os 
aspectos associados com a reação da segurança dos incidentes. Também inclui 
uma avaliação e gerenciamento dos riscos e vulnerabilidade, e implementação de 
custos justificáveis para a implementação de contra-recursos (estratégia de 
segurança). 
 
 
 
Figura 1: ITIL e seus livros 
Fonte:Service Suport OGC 
 
 
Para esta nossa disciplina, vamos estudar apenas os dois primeiros. 
Conforme o livro de Services Suport do ITIL, o relacionamento entre os processos está 
descrito na imagem abaixo. 
 
Figura 2: relacionamento entre processos do Service Suport – ITIL 
Fonte: livro ITIL-SS 
 
 
 
 
Figura 2: conforme figura do livro sobre Entrega de serviços do Service Suport – ITIL e seus 
relacionamentos 
Fonte: livro ITIL-ES 
 
Possíveis ganhos ou economias com ITIL: 
• Redução do custo total em até 48% - Gartner 
• 6-8% de redução de custos operacionais. $ 125 milhões de economia (10% do 
budget). Procter e Gamble 
• Aumento da satisfação do cliente 
• Aumento de resolução de incidentes de 5% para 30% com o uso de uma base de 
conhecimento - IS Organizations 
• Redução de 50% no tempo médio de resolução. Redução de 30% no tempo para 
realizar novas mudanças. Redução de 50% dos recursos – 
• Utility Provider 
Dentre os diversos motivos para de adotar uma estratégia de serviços em ITIL, destaco: 
• Incrementar a qualidade no serviço, com um suporte mais confiável em T.I. 
• Uma percepção e vivência da segurança e confiança da continuidade nos serviços 
de TI. 
• Percepção da capacidade atual mais visível e transparente a todos. 
• Fornecimento de informações gerenciais para acompanhamento de desempenho, 
possibilitando traçar melhorias. 
• Equipe de TI mais motivada: conhecendo a carga de trabalho é possível gerenciar 
melhor as expectativas. 
 
 
• Maior satisfação para os clientes e usuários, entregando o serviço com mais 
qualidade e rapidez. 
• (Em alguns casos) Redução de custos: a partir do melhor planejamento e controle 
dos processos internos é possível otimizar os custos operacionais. 
• Maior agilidade e segurança para realizar as mudanças propostas pelo negócio. 
Com processos definidos e controlados é mais fácil implementar várias mudanças 
simultaneamente. 
O conceito de serviço em T.I. deve ser entendido como sendo um conjunto de objetos 
relacionados, aprovisionados para suporte a um ou mais processo de negócios. 
Diferentemente de processo, em serviços é sempre o usuário que interage. 
A definição de processo em ITIL é a reunião de atividades que são interdependentes e 
inter-relacionadas com uma meta específica. Como componentes mais notáveis pode-se citar: 
entradas de dados, informações, produtos, que transformam os recursos necessários nos 
objetivos previstos. 
 
Figura: exemplo de processo 
Fonte: Pinheiro (2006, 18) 
 
Visando a melhor prestação de serviços em TI, ITIL separa em dois os atores da 
prestação de serviços, a saber: 
Cliente: é quem paga pelos serviços. Caso TI seja uma área interna, os clientes podem 
ser as unidades de negócios ou departamentos da empresa; caso TI seja um terceiro, prestador 
de serviços, os clientes serão, então, as próprias empresas que o terceiro atenderá. 
Usuário: é quem utiliza os serviços de TI quotidianamente. 
Segundo Pinheiro (2006,25), a implementação de uma central de serviços ITIL tem por 
objetivos: 
• Funcionar como o ponto central de contato (SPOC – Single Point of Contact) entre 
os usuários e departamento de TI. A Central de serviços funciona como o 1º. Nível 
de suporte aos usuários. 
 
 
• Restaurar os serviços sempre que possível. A equipe de suporte deve estar 
equipada com ferramentas e informações, tais como Erros Conhecidos, Base de 
Conhecimento, para que possa oferecer soluções o mais rápido possível. 
• Prover suporte com qualidade para atender os objetivos do negócio. É necessário 
que a equipe esteja bem treinada para ter conhecimento de todos os serviços que 
serão fornecidos e entender o impacto que eles têm para o negócio. 
• Gerenciar todos os incidentes até o seu encerramento. A central de serviço será 
responsável pelo processo de Gerenciamento de Incidentes, e será responsável 
pelo tratamento de todos os incidentes. É de responsabilidade também da Central 
de Serviços monitorar o cumprimento dos acordos estabelecidos nas ANS (SLA-
Acordos de Níveis de Serviços). 
• Dar suporte a mudanças, fornecendo comunicação aos usuários sobre o 
agendamento de mudanças. 
• Aumentar a satisfação do usuário, provendo suporte com maior qualidade, estando 
sempre de prontidão para o atendimento, buscando solucionar os incidentes de 
forma mais rápida. 
• Maximizar a disponibilidade do serviço. 
Suas atividades principais dizem respeito a: 
• Receber e gravar TODAS as chamadas dos usuários. 
• Gravar e acompanhar incidentes e reclamações. 
• Prover uma avaliação inicial dos incidentes. 
• Monitorar / escalar incidentes por ANS - Acordo de Nível de Serviço (SLA em 
inglês). 
• Comunicar mudanças planejadas nos níveis de serviço. 
• Encerrar os incidentes com confirmação. 
• Manter os usuários informados sobre o progresso de suas requisições. 
• Produzir relatórios de gerenciamento. 
• Coordenaros grupos de suporte de 2º e 3º nível. 
• Prover informações gerenciais. 
• Identificar necessidades de treinamento dos usuários. 
• Contribuir na identificação de problemas. 
Para o ITIL, existem 3 tipos de central de serviço, conforme Bom (2007, 38): 
• Central de Atendimento (Call Center), atende grandes volumes, utiliza o 
telefone. 
• Central de Suporte (Help Desk), o foco é não perder nenhuma requisição - 
seja abandonada ou não atendida, sua meta é resolver e coordenar incidentes 
servindo como interface. 
• Central de Serviços (Service Desk), mais abrangente, inclui os processos de 
negócio de forma integrada não ficando apenas em incidentes, resolve problemas e 
dúvidas. 
 
 
 
 
Figura: Central de Serviços Local – esquema 
Fonte: Pinheiro (2006,24) 
 
Como toda implementação, pode-se criar barreiras ao sucesso da implementação da 
central de serviços, dentre elas o Service Delivery (2000, 48) expõem: 
• Usuários não ligarem para Central de Serviços, mas tentarem buscar uma solução 
diretamente com uma pessoa que conhece, ou que a ajudou da última vez. 
• A equipe técnica não estar preparada para atender as necessidades do negócio ou 
usuários. 
• Nem todas as partes estão informadas sobre os serviços fornecidos e os níveis de 
serviços acordados, resultando em frustração por parte dos usuários. 
A central de serviços atua sobre duas frentes, a primeira é a gestão de incidentes, a 
segunda gestão de problemas. Entende-se que a gestão de incidentes tem como alvo restaurar 
os serviços o mais rápido possível com o mínimo de interrupção, minimizando os impactos 
negativos nas áreas de negócio. 
Para Pinheiro (2006) e o livro ITIL intitulado Service Delivery (2000), o Processo de 
Gerenciamento de Incidentes tem como objetivos: 
• Resolver os incidentes o mais rápido possível, restabelecendo o serviço normal 
dentro do prazo acordado. 
• Manter a comunicação dos status dos incidentes aos usuários. 
• Escalonar os incidentes para os grupos de atendimento para que seja cumprido o 
prazo de resolução. 
• Fazer avaliação dos incidentes e as possíveis causas informando ao processo de 
Gerenciamento de Problemas. 
Quanto ao gerenciamento de problemas, sua principal tarefa é mitigar a interrupção 
nos serviços de TI, organizando os recursos disponíveis resolvendo o problema conforme as 
 
 
necessidades do negócio, tentando evitar a recorrência e agindo no sentido de documentar 
para promover a melhoria continua da disponibilidade e produtividade. 
De acordo com o Livro ITIL Service Delivery (2000), leva em conta os seguintes 
conceitos gerais: 
• Problema: é a causa desconhecida de um ou mais incidentes 
• Solução de Contorno: solução não definitiva (em inglês Workaround) 
• Causa: é um erro em um Item de configuração 
• Erro Conhecido (Known Error): É um problema cuja causa foi diagnosticada e 
para qual existe uma solução 
• Solução: solução definitiva 
• Gestão de Incidentes X Problemas: foco na Solução rápida x foco na 
introdução de melhorias confiáveis e robustas na infraestrutura 
 
 
 
 
 
 
Caso você queira se aprofundar em ITIL e entender mais detalhadamente as 
funções dos livros de serviços e até poder implementar algumas práticas no 
lugar que você trabalha, sugiro a leitura desta apostila de fundamentos em 
gerenciamento usando ITIL. 
Disponível em: 
http://pt.scribd.com/doc/88136757/10/Fundamentos-em-Gerenciamento-de-
Servicos-de-TI 
 
Outro material interessante já focado na versão 3 do ITIL é este, disponível 
em: http://www.slideshare.net/blogdufraga/apostila-itilv3conceitos 
Existe, disponível nesse link 
http://www.mp.go.gov.br/portalweb/hp/12/docs/apresentacao_gp.pdf, um 
material muito bom sobre um resumo de gestão de projetos para que você 
possa conhecer essa área que cresce a cada dia em nosso país e que tem falta 
crônica de mão de obra. 
 
Para uma leitura mais aprofundada na aplicação do gerenciamento de 
projetos em tecnologia da informação, eu recomendo a leitura do artigo 
intitulado “Aplicabilidade dos Escritórios de Projetos de TI nas organizações 
públicas e privadas”. Este fala um pouco das dificuldades em se implementar 
um escritório de projetos voltado para TI. Disponível em: 
http://www.upis.br/posgraduacao/revista_integracao/projetos_ti%20.pdf 
 
 
 
 
 
 
 
Material Complementar 
Depois de ler o material e informar-se sobre 
o assunto, vamos pôr em prática esses 
conhecimentos nas atividades! 
 
Bom trabalho! 
 
 
 
 
 
 
 
BON, Jan Von. Foundations of IT Service Management, based on ITIL. Lunteren -
Holanda: Van Haren Publishing. 2005. 
 JUNIOR MARQUES, Artur Ubaldo; MARQUES, Daniela Gonçalves de Moraes. 
Gerenciamento do Tempo em Projetos. EAD – Universidade Cruzeiro do Sul, 2011. 
PINHEIRO, Flávio R. Fundamentos em gerenciamento de serviços de TI baseados em 
ITIL. 2006. Disponível em: http://pt.scribd.com/doc/32939973/ Apostila-ITIL. Acessado em: 
22 jul. 2012. 
PMI® – Project Management Institute. Guia PMBOK®. Um Guia do Conhecimento em 
Gerenciamento de Projetos. 4ªEd.. PMI®. 2008. 
 RICARDI, André Luis Fonseca. Gerenciamento do Escopo do Projeto. EAD – 
Universidade Cruzeiro do Sul. 2011. 
 SCHMITZ, Leandro Costa. Gerência de Projetos: Histórico, Contextualização, Principais 
Conceitos e Relações. UDESC/ESAG. 2005. 
 THE STATIONARY OFFICE. Service Delivery. Inglaterra: Londres. 2000 
 
 
 
Referências 
 
 
 
 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
__________________________________________________________________________________________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
_________________________________________________________________________________ 
 
Anotações