1
UNIVERSIDADE CANDIDO MENDES
INSTITUTO A VEZ DO MESTRE
PÓS-GRADUAÇÃO “LATO SENSU”
IMPLANTAÇÃO DA METODOLOGIA DE GESTÃO DE
PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
SEGUNDO OS PADRÕES DO PMI
WALMIR AMOÊDO DO NASCIMENTO
ORIENTADORA
GENI LIMA
Rio de Janeiro
2010
2
UNIVERSIDADE CANDIDO MENDES
INSTITUTO A VEZ DO MESTRE
PÓS-GRADUAÇÃO “LATO SENSU”
IMPLANTAÇÃO DA METODOLOGIA DE GESTÃO DE
PROJETOS DE TECNOLOGIA DA INFORMAÇÃO
SEGUNDO OS PADRÕES DO PMI
Apresentação de monografia à Universidade
Candido Mendes como requisito parcial para
obtenção do grau de especialista em Docência
do Ensino Superior.
Por: Walmir Amoêdo do Nascimento
Rio de Janeiro
2010
3
AGRADECIMENTOS
À minha família, aos meus amigos e à minha
orientadora Geni Lima.
4
DEDICATÓRIA
Dedico este trabalho primeiramente a Deus,
pois sem Ele, nada seria possível.
Aos meus pais, pelo esforço e dedicação.
Aos amigos, pela valorização da minha pessoa
e pelo mútuo aprendizado de vida.
5
RESUMO
Executar projetos de Informática é diferente da maioria dos outros projetos de
empreendimentos (construção, montagem, pesquisa, etc.) pela complexidade,
pela constante dificuldade de visualizar claramente o produto que está sendo
desenvolvido e pelas dificuldades de comunicação entre executor e usuário ou
cliente. Os principais fatores críticos de sucesso para projetos de Tecnologia
da Informação são a gerência efetiva dos projetos, o uso de uma metodologia
consistente customizada para a organização, a definição de métricas para
planejamento e monitoramento dos projetos, e, por fim, a existência de uma
equipe tecnicamente capacitada para o gerenciamento. Nesse aspecto, é
importante destacar o crescimento e a disseminação de conhecimentos por
várias universidades e entidades no mundo. Em particular, o PMI – Project
Management Institute, considerado a mais eficaz metodologia para Gestão de
Projetos de Tecnologia da Informação. Esse trabalho propõe um plano para
implantação, customização e teste de uma Metodologia de Gerência de
Projetos segundo os padrões do PMI – Project Management Institute em
empresas de grande porte.
6
METODOLOGIA
A Implantação da Gestão de Projetos segue as diretrizes adotadas
por cada empresa, adequando seus processos de gestão de desenvolvimento
de produtos e serviços de Tecnologia da Informação ao estabelecido na
Metodologia de Gerenciamento de Projetos do PMI – Project Management
Institute.
Inicialmente foi feito um estudo sobre o PMBOK – A Guide to the
Project Management Body of Knowledge do Project Management Institute,
Standards Committee,
À luz do estudo do PMBOK, foi proposto um roteiro para
implantação da Gestão de Projetos.
Adicionalmente ao que é preconizado pelo PMI, algumas áreas
foram enriquecidas com a contribuição de outros autores da respectiva área,
como por exemplo, a Gestão de Riscos.
Alguns tópicos foram ambientados ao Brasil, como a inclusão do
câmbio monetário e a importação de produtos.
O resultado final é uma proposta para implantação e Gestão de
Projetos em empresas brasileiras de grande porte.
7
SUMÁRIO
INTRODUÇÃO
08
CAPÍTULO 1
11
O PROCESSO INICIAL
CAPÍTULO 2
20
PLANEJAMENTO GERAL DO PROJETO
CAPÍTULO 3
88
PROCESSO DE PLANEJAMENTO EXECUTIVO
CAPÍTULO 4
92
PROCESSO DE CONTROLE GERAL DAS MUDANÇAS
CAPÍTULO 5
104
PROCESSO DE ENCERRAMENTO DO PROJETO
CONCLUSÃO
108
BIBLIOGRAFIA
112
ÍNDICE
115
8
INTRODUÇÃO
O objetivo do presente trabalho é propor um plano para
implantação, customização e teste da Metodologia de Gerência de Projetos de
Tecnologia da Informação segundo os padrões do PMI – Project Management
Institute.
Devido às dificuldades de específicas na condução de projetos de
Tecnologia da Informação e à grande insatisfação das empresas com suas
respectivas áreas de TI, o desafio é encontrar uma forma de implantar uma
Metodologia de Gestão de Projetos de Tecnologia da Informação que resolva
esses impasses, porém sem afetar os cronogramas dos projetos em
andamento,o que poderia causar uma paralisação na implantação da
metodologia.
Executar projetos de Informática é bastante diferente da maioria dos
outros projetos de empreendimentos (construção, montagem, pesquisa, etc.)
pela complexidade, pela constante dificuldade de visualizar claramente o
produto que está sendo desenvolvido e pelas dificuldades de comunicação
entre executor e usuário ou cliente.
A insatisfação das empresas com a pouca habilidade de suas áreas
de informática de desenvolverem produtos estratégicos a custos, prazos e
qualidade demandados pelo mercado vem ficando cada dia mais aparente.
Para suportar tal pressão, é necessário conscientizar-se da importância em
utilizar técnicas gerenciais no dia a dia, e de que projetos diferentes são
gerenciados de maneira diferente e exigem interações diferenciadas com o
usuário ou cliente.
Os principais fatores críticos de sucesso para projetos de Tecnologia
da Informação são a gerência efetiva dos projetos, o uso de uma metodologia
consistente customizada para a organização, a definição de métricas para
9
planejamento e monitoramento dos projetos, e, por fim, a existência de uma
equipe tecnicamente capacitada para o gerenciamento.
Nesse aspecto, é importante destacar o crescimento e a
disseminação de conhecimentos por várias universidades e entidades no
mundo. Em particular, o PMI – Project Management Institute, considerado a
mais eficaz metodologia para Gestão de Projetos de Tecnologia da
Informação.
O objetivo do presente trabalho é propor um plano para
implantação, customização e teste da Metodologia de Gerência de Projetos
segundo os padrões do PMI – Project Management Institute. Os objetivos
específicos são:
-
Adequar a Metodologia de Desenvolvimento de Sistemas;
-
Definir uma Metodologia para Projetos de Infra-estrutura;
-
Definir uma Metodologia para Desenvolvimento de Diretrizes e Padrões
Tecnológicos;
-
Definir uma Metodologia para Pesquisas Tecnológicas;
-
Efetivar treinamentos na metodologia e nas ferramentas (a serem definidas)
para apoio ao planejamento e programação de projetos, não só para
gerentes, mas para todos os membros da equipe;
-
Criar templates (análise de custo benefício, cronogramas, análise de
desempenho, aceite formal) comuns de forma a se obter um padrão de
documentação em todos os projetos;
-
Formar competência interna em gestão de projetos, fazendo com que os
profissionais se certifiquem
e tornem-se membros do PMI, assim como a
empresa;
A hipótese a ser comprovada é que é possível implantar o PMI sem
impactar os projetos em andamento, mudar a cultura da empresa,
principalmente no tocante às práticas de gerência de projetos e negociação de
prazos e custos com os clientes, e assim melhorar o nível de satisfação dos
usuários e clientes com a área de Tecnologia da Informação.
10
Espera-se como resultado desse trabalho gerar um roteiro detalhado
para implantação do PMI em empresas brasileiras de grande porte, o que vai
garantir uma gestão efetiva dos projetos de TI e uma melhora na visão dos
profissionais que atuam nessa área.
11
CAPÍTULO 1
1. O PROCESSO INICIAL
1.1
Project Charter
1.1.1 Histórico
Não existe uma “bala de “prata” capaz de matar o lobisomem.
Porém: um projeto bem planejado,
num ambiente de engenharia de software maduro
e conduzido por um gerente competente
pode infligir sérios ferimentos no monstro..
(YOURDON, 2004)
Executar projetos de Informática é bastante diferente da maioria dos
outros projetos de empreendimentos (construção, montagem, pesquisa, etc.)
pela complexidade, pela constante dificuldade de visualizar claramente o
produto que está sendo desenvolvido e pelas dificuldades de comunicação
entre executor e usuário ou cliente.
Segundo Brooks, em “There is no silver bullet.” (BROOKS, 1986), as
dificuldades essenciais dos projetos de Tecnologia da Informação são:
complexidade, pois o número de componentes inter-relacionados é muito
maior que nos outros tipos de projetos; conformidade, sempre forçada por
pessoas ou instituições; alterabilidade, já que todos os produtos de sucesso
sofrem alterações durante o processo de desenvolvimento do projeto; e
invisibilidade uma vez que realidade do software não é espacial.
12
Para complicar, o ambiente de informática sempre foi arredio a
influências externas das técnicas de administração e assim foi criando seu
próprio mundo e se mantendo por muito tempo dentro do “aquário”. Em parte,
isto se explica pelo fato de que os primeiros profissionais a fazer carreira foram
programadores que tinham um forte embasamento técnico, mas geralmente
eram fracos administrativa e gerencialmente.
Outro aspecto que deve ser observado é a dificuldade de
comunicação entre o departamento de informática e o restante da empresa, à
qual Charles Wang (WANG, 1995) denomina de DESCONEXÃO, ou seja,
“conflito,
penetrante,
não
natural,
que
desalinha
os
objetivos
de
administradores executivos e técnicos, e que prejudica ou impede as empresas
de obterem um eficaz retorno sobre os custos do investimento em tecnologia
da informação”.
A desconexão é uma lacuna entre a administração das empresas e
os profissionais da área tecnológica – um estado de incompreensão mútua
causado por diferenças em treinamento, temperamento e tradição.
Segundo Wang (WANG, 1995), os fracassos da tecnologia da
informação surgem como uma avalanche de incidentes não relacionados que
remetem, na maioria das vezes, ao hardware, ao software e a episódios
tecnológicos ou gerenciais aleatórios. A verdade, entretanto, é muito mais
complexa. Principalmente porque muitos executivos ainda tratam a área de
Informática como uma caixa preta, uma área da empresa que fala uma outra
língua, e por vezes impossível de gerenciar. Por mais simples que seja culpar a
tecnologia e os computadores pelas dificuldades, o fato é que estamos falando
principalmente de postura administrativa.
Enquanto
pensarmos
na
desconexão
como
uma
questão
tecnológica, não poderemos começar a resolvê-la. Sim, muitos projetos de
informatização não vingam, estão sempre atrasados, orçamentos caríssimos e
muitos apresentam defeitos. Se o problema for da computação, o argumento é
13
logicamente cabível, e então compete ao pessoal da tecnologia da informação
resolvê-lo.
Mas, normalmente, a desconexão nada tem a ver com os
computadores. É um problema de administração sênior e que não pode ser
delegado.
Por estes e outros motivos, inúmeros casos de fracasso vem sendo
acumulados na história desta indústria.
Eliminar esses problemas abrange uma mudança fundamental em
quase tudo relacionado à aplicação da tecnologia da informação. As
mudanças, porém, no todo não serão tecnológicas. Não será uma questão de
construir redes melhores ou sistemas mais confiáveis, muito menos de
qualificação técnica. Tais providências exigem que lancemos um olhar
irreversível ao nosso próprio comportamento ao longo dos anos e façamos
correções.
Nesta década, diversos fatos novos estão colaborando para
modificar este cenário. Vivemos em um cenário de múltiplos projetos com
grandes dependências interdepartamentais, onde o tempo em que as
mudanças ocorrem é cada dia menor.
A insatisfação das empresas com a pouca habilidade de suas áreas
de informática de desenvolverem produtos estratégicos a custos, prazos,
qualidade demandados pelo mercado vem ficando cada dia mais aparente.
Para suportar tal pressão, é preciso que a comunidade de informática mude.
Que se conscientize da importância em utilizar técnicas gerenciais em seu dia
a dia, de que projetos diferentes são gerenciados de maneira diferente e
exigem interações diferenciadas com o cliente/usuário.
14
Estudos realizados por Capers Jones (JONES, 2010) relacionam as
características comuns dos principais casos de sucesso em projetos de
Tecnologia da Informação nos últimos 10 anos:
planejamento de projetos;
estimativa de custo;
acompanhamento de projetos;
uso de métricas;
controle de qualidade;
gerência de alterações;
metodologia de desenvolvimento;
gerentes de projetos qualificados;
pessoal técnico qualificado e especializado;
reuso de material.
Em resumo, os principais fatores críticos de sucesso para projetos
de TI são a Gerência efetiva dos projetos, o uso de uma metodologia
consistente customizada para a organização, a definição de métricas para
planejamento e monitoramento dos projetos, e, por fim, a existência de uma
equipe tecnicamente capacitada para o gerenciamento.
Um resultado desse novo foco em gerenciamento de projetos e
processos de Tecnologia da Informação são o crescimento em vendas do
Microsoft Project de cerca de US$ 50 milhões anualmente há poucos anos
atrás para mais de US$ 300 milhões em 2008. Pesquisas do Gartner Group
apontam que em 2003 mais de metade das organizações de TI estarão
utilizando mais de 75% do seu tempo total em gerenciamento de projetos
(com 70% de probabilidade de ocorrência).
A razão desse sucesso está em que o gerenciamento de projetos
apregoa um método sistemático, metódico que propicia o controle de
empreendimentos e que podem ser utilizados para os projetos de Tecnologia
da Informação.
15
Nesse aspecto, é importante destacar o crescimento e a
disseminação desses conhecimentos por várias universidades e entidades no
mundo. Em particular, citamos o caso do PMI – Project Management Institute,
um organismo fundado em 1969 no EUA e que durante muitos anos de
existência seu número de associados variou de 6.000 a 8.000, no entanto em
meados da década de 2000, essa quantidade ultrapassou os 25.000,
atualmente conta com 45.000 e com uma taxa de crescimento de adesão de
pelo menos 3.000 a cada ano.
Sabendo que na maioria das grandes empresas brasileiras o cenário
real não é diferente do apresentado acima, é preciso formalizar técnicas,
ferramentas e métodos que assegurem tanto o gerenciamento eficaz dos
projetos de sistemas de informação e tecnologia para seus clientes quanto
aqueles de desenvolvimento interno de metodologias, padrões, diretrizes e
pesquisa de novas tecnologias.
Em seu Plano de Gestão da Informática – PGI, essas empresas
devem assumir como premissa básica para seu sucesso a necessidade do
gerenciamento de projetos suportado por processos que garantam o
comprometimento da área de Tecnologia da Informação e das áreas
solicitantes quanto ao escopo, prazo e recursos. Esses processos devem ser
padronizados, com definição clara de papéis e responsabilidades, amplamente
divulgados e revisados constantemente.
1.1.2 Objetivo
Este projeto apresenta um plano para implantação, customização, e
teste da Metodologia de Gerência de Projetos segundo os padrões do PMI –
Project Management Institute na área de Tecnologia da Informação de
empresas de grande porte.
16
1.1.3 Descrição do Produto
Como resultado da implantação da metodologia, espera-se obter a
definição de rotinas, ferramentas de trabalho, atribuições, responsabilidades e
formação de expertise em gerencia de projetos e o planejamento da
implementação do modelo de gestão PMI (PMI, 2004) nas empresas ,
abordando os seguintes itens:
Adequação da Metodologia de Desenvolvimento de Sistemas;
Definição de Metodologia para Projetos de Infra-estrutura;
Definição de Metodologia para Desenvolvimento de Diretrizes e Padrões
Tecnológicos;
Definição de Metodologia para Pesquisas Tecnológicas;
Definição de Metodologia para Projetos de Gerenciamento de Tecnologia
da Informação;
Adequação da Metodologia de Desenvolvimento de projetos de Tecnologia;
Análise de viabilidade de implantação de um Project Office na área de
Tecnologia da Informação;
Efetivar treinamentos na metodologia e nas ferramentas (a serem definidas)
para apoio ao planejamento e programação de projetos, não só para
gerentes, mas para todos os membros da equipe;
Criação de templates (Análise de Custo Benefício, cronogramas, análise de
desempenho, aceite formal) comuns de forma a se obter um padrão de
documentação em todos os projetos efetivados pela área de Tecnologia da
Informação;
Escolha e execução de um projeto piloto para demonstração dos resultados
do uso da gerência de projetos;
Formação de competência interna em gestão de projetos, fazendo com que
os profissionais se certifiquem e tornem-se membros do PMI, assim como a
empresa.
1.2
Gerente de Projeto
17
As atividades de gestão de projeto deverão ser exercidas por um
Analista de Sistemas que possua todas as atribuições, direitos e deveres de tal
função.
1.3
Restrições
A Metodologia deverá ser implantada em 12 meses.
1.3.1 Orçamento
Foi previsto um orçamento pluri-anual de US$ 300 mil a serem desembolsados
em 2 anos.
1.4
Premissas
Foram consideradas as seguintes premissas:
Os cronogramas dos projetos em andamento não poderão ser afetados
pela implantação da metodologia;
Deverão ser alocados representantes de todas as Gerências de área de
Tecnologia da Informação;
Será desenvolvido um projeto piloto como
forma de testar a nova
metodologia e impedir que um eventual fracasso aconteça no primeiro
projeto e que comprometa a imagem da área de Tecnologia da Informação;
Mudança de cultura da empresa, principalmente no tocante às práticas de
gerência de projetos e negociação de prazos e custos com os clientes;
Os treinamentos serão contratados.
18
1.4.1 Fatores Críticos de Sucesso
A definição da metodologia de gestão de projetos PMI não garante
por si só atingir o seu objetivo de produzir sistemas com melhor qualidade,
dentro do escopo, prazo e custo pré-definidos e com a satisfação garantida
aos clientes da área de Tecnologia da Informação.
Existem alguns fatores muito importantes para se atingir esses
objetivos:
Comprometimento e apoio explícito da alta gerência de informática;
Consultoria experiente na implantação da metodologia;
Patrocínio do projeto pelo principal cliente (sponsor ship);
Formalização da figura do Gerente de Projeto na estrutura de atendimento
da área de Tecnologia da Informação;
Existência de gerente de projeto experiente e bem treinado;
Existência de apoio administrativo para elaboração de documentos.
1.4.2 Benefícios
Os benefícios esperados são:
Padronizar a forma de gerenciamento para que a área de Tecnologia da
Informação consiga fazer a programação integrada de informática;
O
Planejamento
dimensionar
os
e
Programação
recursos
detalhados
necessários
do
projeto
adequadamente
permitem
sendo
uma
ferramenta para monitoramento do projeto;
Assegurar que o projeto inclua todo trabalho necessário para o seu
sucesso;
Fornece informações necessárias ao patrocinador do projeto quanto ao seu
andamento, custos e prazos;
Formação de uma base de dados para aperfeiçoar o processo de
estimativa de prazos e custos de futuros projetos de tecnologia da
informação;
19
Assegurar o planejamento e execução do projeto em um prazo adequado;
Assegurar que o projeto possa ser executado dentro do orçamento
aprovado;
Assegurar que o projeto satisfaça as necessidades para o qual foi
concebido;
Melhor uso dos recursos humanos envolvidos no projeto;
Assegurar adequada geração, disseminação e armazenamento de
informações do projeto.
20
CAPÍTULO 2
2. PLANEJAMENTO GERAL DO PROJETO
2.1
Planejamento do Escopo
2.1.1 Justificativa do Projeto
Os projetos de Tecnologia da Informação (TI) têm poucos registros
de sucesso para festejar. No Brasil, a maioria das empresas de grande porte
não foge à regra. Porém, não existem métricas sistematizadas para podermos
avaliar a real extensão dos problemas.
Embora a mudança na organização de Tecnologia da Informação
seja percebida como um fator positivo, a falta de direcionadores para a gestão
da função informática impede o adequado gerenciamento e controle da mesma
por parte da área de Tecnologia da Informação.
21
Fatores Críticos para o Sucesso
S
• Qualidade dos Serviços
S
• Confiabilidade dos Serviços
I
S
• Imagem da area de TI
S
• Recursos Técnicos Disponíveis
• Preço/Custo
S
• Cumprimento de Prazos
S
• Empatia no Entendimento das
.
Grau de Importância (1-5)
S
Grau de Satisfação (1-5)
I
I
S
S
Unid.
I
S
0
1
I
I
Unid.
• Capacitação do Pessoal de T I
.
I
S
• Capacitação Técnica do Pessoal de TI
I
I
I
S
• Atendimento (Agilidade/Flexibilidade)
• Grau de Customização às
I
2
I
3
4
5
Fonte: Sessões de trabalho com as áreas de TI
Como conclusão, observa-se um “gap” em relação ao grau de
importância esperado pelos clientes versus o grau de satisfação percebido. O
atendimento das expectativas da organização são o maior de todos os fatores
que determinam como usuários e executivos vêm sua organização de
Tecnologia da Informação.
Os maiores “gaps” estão relacionados a preço/custo, cumprimento
de prazos, agilidade e flexibilidade e confiabilidade (escopo e qualidade)
afetando a imagem da área de Tecnologia da Informação.
A resposta para solução desses problemas passa essencialmente
pelo gerenciamento de projetos. A implantação de uma metodologia de
gerenciamento de projetos terá significativo impacto na efetividade da entrega
de produtos e na eficiência do gerenciamento da infra-estrutura de Tecnologia
da Informação.
Face à inexistência de dados estatísticos internos procurou-se
encontrar números na literatura que permitam quantificar os problemas
gerados pelo gerenciamento inadequado dos projetos de Tecnologia da
Informação.
22
Um estudo realizado por Capers Jones (JONES, 2010) em 6700
projetos de 500 empresas americanas conclui que:
Projetos de Tecnologia da Informação são atividades de risco;
A taxa de falhas em projetos de TI é muito maior que nas outras atividades;
Falhas em projetos de TI são mais freqüentes do que os sucessos ( risco
maior que 50%), ou seja, se houvesse um seguro para projetos de TI, o seu
prêmio seria da ordem de 50%, o mais alto de todos os outros tipos de
seguro;
Taxas de falhas em projetos: aumentam com o tamanho do projeto;
Os projetos que falham não apresentam:
dados históricos de outros projetos
ferramentas de planejamento e estimativa
acompanhamento contínuo
metodologia de desenvolvimento
revisões e inspeções periódicas
gerência de risco
gerência de requisitos
gerência de configuração
teste formal
pressão excessiva no cronograma
rejeição das estimativas pelos executivos
atritos com clientes
política interna
falta de comunicação na equipe
executivos ingênuos com problemas de SW
qualificação em gerência de projetos
qualificação técnica da equipe;
Os projetos que obtém sucesso apresentam:
planejamento de projetos
estimativa de custo
acompanhamento de projetos
uso de métricas
23
controle de qualidade
gerência de alterações
metodologia de desenvolvimento
gerentes de projetos qualificados
pessoal técnico qualificado e especializado
reuso de material.
Outro estudo realizado por Thamhain e Willemon (THAMHAIN &
WILEMON, 1974) com entrevistas com 304 gerentes de projeto e analisando
108 projetos de porte das áreas de eletrônica, petroquímica, construção e
farmacêutica chegou às seguintes razões para as falhas dos projetos em geral:
Falta de planejamento
Plano de projeto não-realístico
Subestimar o escopo do projeto
Alterações no cliente ou na gerência
Falta de planejamento das contingências
Inabilidade para acompanhar o progresso
Inabilidade de detectar os problemas antecipadamente
Poucos pontos de controle
Poucas pessoas na equipe
Complexidade técnica do projeto
Mudanças de prioridade
Falta de comprometimento da equipe
Falta de motivação da equipe
Pessoal não qualificado
Em 2010, uma pesquisa do Standish Group (STANDISH GROUP
INTERNATIONAL, 2010) concluiu que, dos projetos de informática de 365
empresas americanas, 31% foram cancelados antes de prontos (com um custo
de US$ 81 milhões), 53% estouraram mais de 90% no custo previsto (a um
preço de 59 bilhões de dólares), 13% estouraram mais de 200% e apenas 16%
foram concluídos dentro do prazo e do orçamento.
24
PROJETOS DE INFORMÁTICA
Abortados
31%
Sucesso
16%
Alterados
53%
Encontrou-se, ainda, na literatura:
Mais da metade de todos os projetos de TI não atendem aos benefícios
esperados (GARTNER GROUP, 2010);
Aproximadamente 99% dos softwares comerciais não terminam no tempo e
os custos em média são subestimados em 285% (PMI ORANGE COUNTY
CHAPTER , 2010);
Cerca de 50% do tempo dos profissionais de desenvolvimento de software
é gasto para encontrar e corrigir “erros” (DAYCHOUM, 2007);
São necessárias em média 12 horas para corrigir um erro ou realizar uma
alteração complexa (VARGAS, 2006).
O quadro é caótico e com certeza não muito longe da realidade
brasileira.
O modelo de gestão de informática proposto tem como premissas
que a área de Tecnologia da Informação faça a gestão centralizada da
informática dentro do modelo de terceirização das atividades não estratégicas,
padronização e consolidação dos orçamentos e distribuição dos recursos e
priorização dos projetos por Diretoria.
25
Não será possível realizar essa tarefa sem que se implante na área
de Tecnologia da Informação uma metodologia de gerenciamento de projetos
de nível mundial, com definição das métricas de planejamento, formação de
uma base de conhecimento compartilhada e uma equipe de gerentes de
projeto capacitados.
2.1.2 Plano do Gerenciamento do Escopo
Assim como alterações no prazo de execução de projetos, as
mudanças de escopo exercem forte influencia em todos os demais processos.
E sua ocorrência é muito acentuada, pois na maioria dos projetos de
informática, o envolvimento dos interessados durante a execução leva a
alterações de escopo para melhor atender suas necessidades.
Para poder controlar o escopo a equipe necessitará do WBS
atualizado de forma a verificar se as atividades previstas foram ou não
executadas.
As solicitações de mudança no escopo deverão ser feitas através de
procedimento padrão estabelecido pela equipe do projeto. Deverá ser
formalizado através de um documento denominado “Pedido de Alteração de
Escopo”. Neste documento estará registrado o impacto técnico, o impacto no
custo e o impacto no tempo e deverá ser autorizado pelo gerente da área
solicitante do projeto. A equipe do projeto deverá levar à revisão do
planejamento, fazendo novo WBS e obter sua aprovação.
Em qualquer situação de mudança de escopo, os envolvidos devem
ser apropriadamente comunicados de acordo com o plano de comunicação.
26
2.2
Definição do escopo
O projeto foi dividido em 6 fases a seguir:
Iniciação
Nesta fase serão feitas atividades para comprometer a organização e
conseguir o apoio explicito da gerencia para a implantação da Gestão de
Projetos na área de Tecnologia da Informação.
Planejamento do Projeto
Nesta fase estará sendo estabelecido o plano geral do projeto contendo todas
as atividades, cronograma, recursos, custos, orçamento, plano de qualidade,
plano de comunicação, plano de gerenciamento de riscos e plano de
contratação.
Contratação
Nesta fase estarão sendo feitas todas a aquisições e contratações para a
execução do projeto.
Execução e Controle:
Customização das metodologias da área de Tecnologia da Informação
acrescentando os processos de gestão de projetos do PMI. Nesta fase
acontecerá a escolha do projeto que inicialmente utilizará a nova sistemática
de gerenciamento de projetos. As ferramentas e processos que foram
definidos, serão experimentados para garantir se estão adequados ou não ao
ambiente da empresa.
Produção:
Nesta fase será feito o levantamento de todos os projetos em andamento, e
serão definidos quais se adequarão a metodologia e será estabelecido o
planejamento de suas adequações.
Encerramento do projeto:
27
Nesta fase haverá a revisão de todos os procedimentos, encerramento dos
contratos, análise da lição aprendida e criação de todo acervo técnico e
encerramento de todos os contratos.
2.2.1 Estrutura Analítica do Projeto (WBS)
WBS
Implantação de Gestão de Projetos na TI
Fase
Iniciação
2.3
Fase
Fase
Planejamento Aquisições e
d
Contratações
Implantação
Fase
Execução
Controle
Fase
Produção
Fase
Encerrament
Planejamento da Qualidade
2.3.1 Política de Qualidade da Empresa
A Área de TI é a fornecedora de recursos de Tecnologia da
Informação e Telecomunicações, provendo infra-estrutura, disponibilizando
produtos e serviços, dando apoio técnico e/ou realizando planejamento e
projetos, nos graus e níveis requeridos pelas diversas áreas da empresa.
Cada empresa possui uma Política de Qualidade própria que deverá
ser aproveitada para a gestão de seus projetos de informática.
Desta forma a qualidade tratada dentro dos projetos desenvolvidos
pela área de Tecnologia da Informação deverá ser compatível com a Política
de Qualidade da empresa e com a Organização Internacional de Normas –
ISO, conforme detalhado nas séries de normas e guias 9000 e 10000.
28
O gerente do projeto deverá buscar o gerenciamento da qualidade
de seus projetos e a satisfação de seus clientes e colaboradores, o
gerenciamento da rotina através da participação de todos e no futuro obter o
Certificado de Garantia da Qualidade – ISO 9002.
2.3.2 Política de Qualidade da Área de Tecnologia da Informação
Cliente
A Área de Tecnologia da Informação vai satisfazer as necessidades dos
clientes oferecendo produtos e serviços de qualidade, atendendo interesses
recíprocos.
Melhoria
A Área de Tecnologia da Informação trabalhará com contínuas melhorias da
qualidade para assegurar a excelência de seus produtos.
Treinamento
A qualidade é um investimento que só alcança bons resultados quando
treinamento e tecnologia são integrados. Assim, a Área de Tecnologia da
Informação orienta seu negócio através da produtividade e satisfação de seus
empregados.
Parceria
A Área de Tecnologia da Informação vai intensificar intercâmbios técnicos e
comerciais com seus clientes, culminando numa parceria em qualidade.
Comprometimento
Aumento do sucesso no futuro se dará com o comprometimento de todos os
empregados com a qualidade.
29
2.3.3 Missão da Área de Tecnologia da Informação
Contribuir para o aumento da competitividade dos negócios da
empresa, provendo soluções que assegurem a sua integração, promovam a
sua diferenciação e aumentem sua eficiência empresarial, através da aplicação
do tratamento da informação.
2.3.4 Crenças e Valores
Direcionar a atuação à satisfação das necessidades e ao sucesso dos
clientes;
Estar sempre atento às oportunidades de mudanças, modernização e
diferenciação competitiva nos negócios da empresa;
Ser o principal e mais qualificado prestador de serviços de Tecnologia da
Informação para a empresa;
Estar permanentemente comprometido com a qualidade dos produtos e
serviços;
Promover um ambiente de trabalho participativo, que respeite o indivíduo,
estimule o esforço em equipe e valorize a criatividade;
Oferecer aos empregados desafios profissionais, oportunidades de
desenvolvimento e remuneração compatíveis com o seu desempenho,
responsabilidade e comprometimento;
Observar sempre os mais elevados padrões éticos nos trabalhos e no
relacionamento com clientes e fornecedores;
Estimular nos clientes e fornecedores uma atitude de parceria na prestação
de serviços;
30
Dar à empresa o melhor retorno dos investimentos em Tecnologia da
Informação;
Exigir de todos o comprometimento a estas crenças e valores e às da
empresa.
2.3.5 A Implantação da Gestão de Projetos e a Qualidade
A Implantação da Gestão de Projetos na Área de Tecnologia da
Informação seguirá as linhas adotadas pela empresa adequando seus
processos de gestão de desenvolvimento de produtos ao estabelecido na
Metodologia de Gerenciamento de Projetos do PMI – Project Management
Institute.
Para o gerenciamento da qualidade nos projetos da Área de
Tecnologia da Informação deverão ser atendidas as seguintes premissas:
A satisfação das necessidades definidas e implícitas dos clientes e
interessados é prioritária. No caso da implantação da gestão de projetos em
curso, deve-se administrar tal satisfação de forma a contornar insatisfações
originadas por resistências às mudanças em curso e outras;
O projeto deve ser tratado como um todo, lembrando-se de gerenciar a
qualidade dos grupos de processos interdependentes;
O foco da qualidade deve ser equilibrado entre os processos e o produto
final;
O gerente deve ser o responsável pela criação do ambiente favorável à
qualidade;
A administração é responsável pela melhoria contínua.
2.3.6 Sistema da Qualidade
31
2.3.6.1
Definição
Documentar e manter um Sistema da Qualidade como meio de
assegurar que os produtos/serviços estejam em conformidade com os
requisitos dos clientes.
2.3.6.2
Objetivo
Estabelecer regras documentadas que garantam o funcionamento
eficiente e eficaz dos sistemas, objetivando o pleno atendimento dos requisitos
estabelecidos para prover soluções e ferramentas de alta tecnologia aos
clientes.
2.3.6.3
Aplicação
O Sistema da Qualidade é formado por um conjunto de documentos
normativos de controle centralizado e documentos comprobatórios de controle
descentralizado, conforme o quadro abaixo:
NÍVEL
TIPO
Estratégico
Manual da Qualidade
Tático
Procedimentos
Operacional
FINALIDADE
CONTROLE
Normativa
Centralizado
Comprovação
Descentralizado
Instruções de trabalho
Registros da Qualidade
32
2.3.6.4
Planejamento da Qualidade
O Planejamento da Qualidade define, através do Sistema da
Qualidade, como os requisitos do Sistema da Qualidade da Área de
Tecnologia da Informação são atendidos.
Os planos da qualidade estão diluídos na documentação que
compõe o Sistema da Qualidade, nos procedimentos, nas instruções de
trabalho e nos registros da qualidade.
2.3.6.4.1 Métricas da Qualidade
Os planos de qualidade apresentadas a seguir são checklist básicos
com as características de qualidade e métricas dos produtos que serão
monitoradas pelo Gerente do Projeto ao longo das fases de execução do
projeto.
2.3.6.4.2 Customização das metodologias da Área de Tecnologia da
Informação ao PMI
Item Fase
Processo
3
Validação
% de itens
aprovados
Auditoria
% de itens não
aderentes à
metodologia
% de erros de
digitação/
ortografia
% de volumes
entregues
Customização das
Metodologias
Revisão
Distribuição
Característica
da Qualidade
Valor
Quando
Medir
>=95%
A cada
dos itens
reunião de
analisados
validação
0%
No aceite de
cada capítulo
0%
100%
No aceite
das
metodologias
1 semana
após o aceite
33
2.3.6.4.3 Capacitação
Item
Fase
Processo
3
Treinamentos
Capacitação
Característica
da Qualidade
% de pessoal
treinado
Valor
Quando
Medir
>=80% do
programado
>= 70%
Mensal
A cada turma
Avaliação
aprendizado
de Resultado de testes
Avaliação
treinamento
do
Nível geral de
satisfação
>=B
A cada turma
Cronograma
cursos
de
Número de
alterações de data
0
Mensal
2.3.6.4.4 Aquisições e Contratações
Item Fase
Processo
3
Especificação
Contratações
Aquisições
Característica
da Qualidade
Valor
Quando
medir
# de devoluções
para correção
0
Semanal
Coleta
# de recoletas
0
Semanal
Custo
Variação em
relação ao orçado
±5%
Prazo
Atrasos
0 dias
Data Limite
xx/xx/xxxx
Sim/Não
# de devoluções
para correção
0
Durante a
fase de
negociação
Até
assinatura do
contrato
A cada
reunião
semanal
Semanal
Coleta
# de recoletas
0
Semanal
Custo
Variação em
relação ao orçado
±5%
Prazo
Atrasos
0 dia
Na
homologação
da compra
Semanal
Data Limite
xx/xx/xxxx
Sim/Não
Emissão do
Pedido de
Contratação
Especificação
Emissão do
Pedido de
Material
A cada
reunião
semanal
34
2.3.6.4.5 Implantar a Metodologia em Produção
Item Fase
Produção
Processo
Característica
da Qualidade
Valor
Quando
Medir
Levantamento
% dos projetos em
andamento
100% do
planejado
Semanal
Planejamento
% de projetos a
serem adequados
100% do
planejado
Semanal
Nível geral de
satisfação
>=B
No aceite do
planejamento
Característica
da Qualidade
Valor
Quando
medir
Prazo
Atrasos
0
Semanal
Custo
Variação em
relação ao orçado
±5%
Semanal
Número de
processos não
aderentes
Número de
correções na
metodologia
% de itens
aprovados
0
No aceite de
cada fase
>0 e <20
No aceite de
cada fase
>=95%
No aceite de
cada fase
Avaliação
do
planejamento
2.3.6.4.6 Projeto Piloto
Item Fase
Desenvolvimento do
Projeto Piloto
Processo
Efetividade
Revisão
da
Metodologia
Validação da
Metodologia
2.3.6.4.7 Registros da Qualidade
São todos os procedimentos, instruções de trabalho e demais
documentos, relacionados no plano de comunicação, que servirão para
monitorar os itens de controle e efetivar as ações corretivas, preventivas,
imediatas e de melhorias operacionais.
O processo de monitoramento e registro das não conformidades e
tomada de ação estão apresentados no processo e ferramentas de controle de
qualidade.
35
2.4
Planejamento Organizacional
O planejamento organizacional envolve identificar, documentar e
designar as funções, responsabilidades e relacionamento de reporte dentro do
projeto.
A estrutura funcional definida para a implantação da metodologia
PMI na Área de Tecnologia da Informação é constituída pelo gerente de
projeto, dois consultores, um analista de cada área funcional da Área de
Tecnologia da Informação e empresa de outsourcing contratada para o
desenvolvimento do projeto piloto.
36
Recurso
RH
Cargo
Diretor de
Recursos
Humanos,
Administração e
Informática
Gerente Geral de
Informática
Descrição do Cargo
Atribuição
Descrito no Plano de Aprovar o orçamento;
Cargos e Salários da Estimular a sinergia entre as diversas
Companhia
áreas funcionais da TI para que o
projeto tenha sucesso;
Comprometer a organização
TI
Descrito no Plano de Estimular a sinergia entre as diversas
Cargos e Salários da
áreas funcionais da TI para que o
Companhia
projeto tenha sucesso;
Comprometer a organização;
Aprovar todos os produtos;
Gerente
Gerente de Área
Descrito no Plano de Liberar os recursos para participação
de Área
Cargos e Salários da
no projeto;
(GA)
Companhia
Comprometer a organização;
Estimular a sinergia entre as diversas
áreas funcionais da TI para que o
projeto tenha sucesso;
Aprovar todos os produtos.
Gerente
Gerente de Projeto Descrito no Plano de Controlar
o
andamento
da
de Projeto
Cargos e Salários da
implantação da Gestão de Projetos;
(GP)
Companhia
Emitir relatório de controle para a
gerência
geral
de
informática
informando o avanço físico e
financeiro do projeto;
Controlar o orçamento do projeto;
Aprovar contratações de consultoria
e licença do software;
Controlar a qualidade do projeto;
Manter o moral da equipe elevado;
Efetuar avaliação de desempenho da
equipe;
Definir o escopo;
Ser responsável pelo planejamento
Aprovar
normas,
padrões
e
procedimentos;
Proceder ao fechamento do projeto;
Ser o interlocutor da equipe de
implantação
com
os
demais
envolvidos.
37
Recurso
Consultor
Cargo
Consultor
Descrição do Cargo
Especialista em
Metodologia de
Gerenciamento de
Projetos do PMI, com
experiência mínima de
3 anos no mercado.
Atribuição
Trazer experiências de outras
implantações;
Definir padrões e critérios;
Promover discussões de assuntos
específicos;
Orientar no desenvolvimento do
projeto
Ministrar treinamentos nas
ferramentas selecionadas;
Instrutor
Instrutor
Analista
Sistemas
(AS)
Analista de
sistemas
Especialista em
Ferramentas
Gerenciamento de
Projetos, com
experiência mínima de
1 ano no mercado
Descrito no Plano de Cargos e Salários da
Companhia
Analista
Infra (AI)
Analista de Infra- Descrito no Plano de estrutura
Cargos e Salários da
Companhia
Analista
Analista de
tecnologia Tecnologia
(AT)
Descrito no Plano de Cargos e Salários da
Companhia
Analista
planejamento
(AP)
Analista de
Planejamento
Gestor
Cliente
(GC)
Analista
Descrito no Plano de Cargos e Salários da
Companhia
Descrito no Plano de Cargos e Salários da
Companhia
Definir a adequação da metodologia
desenvolvimento de sistemas;
Participar do planejamento geral;
Participar da definição de escopo;
Participar do controle de orçamento;
Participar do controle de qualidade;
Participar da definição de escopo.
Definir metodologia para projetos de
Infra-estrutura;
Participar do planejamento geral;
Participar da definição de escopo;
Participar do controle de orçamento;
Participar do controle de qualidade;
Participar da definição de escopo.
Definir metodologia para projetos de
pesquisa tecnológicas
Participar do planejamento geral;
Participar da definição de escopo;
Participar do controle de orçamento;
Participar do controle de qualidade;
Participar da definição de escopo.
Definir metodologia para projetos de
Gerenciamento de TI
Participar do planejamento geral;
Participar da definição de escopo;
Participar do controle de orçamento;
Participar do controle de qualidade;
Administrar os contratos;
Participar da definição de escopo.
Definir metodologia para projetos de
Gerenciamento de TI
Participar do planejamento geral;
Participar da definição de escopo;
Participar do controle de orçamento;
Participar do controle de qualidade;
Participar da definição de escopo.
38
2.4.1 Matriz de Responsabilidades
Item
Fase/Tarefa
R
H
1
Iniciação
1.1
Apresentar Metodologia PMI para Alta Direção
1.2
Comprometer a organização
1.3
Nomear Gerente do Projeto de Implantação
1.4
Definir Equipe de Planejamento
1.5
Preparação da Equipe para o projeto
2
Planejamento da Implantação
2.1
Planejamento do Escopo
2.2
Definição do Escopo
2.3
Aceitação Formal do Escopo
2.4
Definição das atividades
2.5
Sequenciamento das atividades
2.6
Planejamento dos Recursos
2.7
Estimativa de Duração das Atividades
2.8
Desenvolvimento do cronograma
2.9
Estimativa / Orçamento dos custos
2.10
Consolidação do Orçamento do Projeto
2.11
Aprovação do orçamento do projeto
2.12
Desenvolvimento do Plano do Projeto
2.12.1
Planejamento da Qualidade do projeto
2.12.2
Planejamento das Comunicações
2.12.3
Planejamento dos Riscos
2.12.3.1 Identificação dos Riscos
2.12.3.2 Quantificação dos Riscos
2.12.3.3 Desenvolvimento das respostas aos riscos
2.12.4
Planejamento de Recursos Humanos
2.12.4.1 Planejamento Organizacional
2.12.4.2 Montagem da equipe
2.12.5
Planejamento da Gestão das Aquisições
2.12.5.1 Planejamento das Aquisições
2.12.5.2 Preparação das Aquisições
2.12.6
Aprovação do Plano do Projeto
3
Aquisições e Contratações
3.1
Contratar Consultoria PMI
3.2
Contratar Demais Consultorias
3.3
Contratar Outsourcing Desenvolvimento Piloto
3.4
Contratar Treinamentos
3.5
Adquirir Cópias de Softwares
3.6
Administração de Aquisições e Contratações
4
Execução e Controle
4.1
Capacitação
4.1.1
Definir Grade de Treinamento
4.1.2
Cronogramar Treinamentos
4.1.3
Executar Treinamentos
4.1.4
Controlar Treinamentos
4.2
Customização Metodologias ao PMI
4.2.1
Desenvolvimento de Sistemas de Informação
4.2.2
Projetos de Infra-estrutura
4.2.3
Diretrizes e Padrões Tecnológica
4.2.4
Pesquisas Tecnológicas
4.2.5
Gerenciamento de TI
4.2.6
Avaliar Implantação de um Projeto Office
4.2.7
Encerramento da Customização
Legenda Recursos:
RH = RH
TI = TI
Gp = Gerente Projeto
Gc = Gestão Clientes
Ai = Analista Infra
At = Analista tecnologia
Co = Consultor
In = instrutor
Ct =Contratação
Su = suprimento
TI
RECURSOS
Ga Gp Gc As Ai At Ap Co In
Ou Ct
Su
P
P
-
R
R
R
-
P
P
P
A
-
R
R
P
P
P
P
P
E
E
-
-
-
-
R
P
P
R
R
R
R
R
R
R
R
R
R
-
E
E
E
E
E
E
E
E
E
E
-
E
E
E
E
E
E
E
E
E
E
-
E
E
E
E
E
E
E
E
E
E
-
E
E
E
E
E
E
E
E
E
E
-
E
E
E
E
E
E
E
E
E
E
-
E
E
E
E
E
E
E
E
E
E
-
-
-
-
-
-
-
-
R
R
E
E
E
E
E
E
E
E
E
E
E
E
-
-
-
-
-
-
-
R
R
R
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
E
-
-
-
-
-
-
-
R
R
E
E
E
E
E
E
E
E
E
E
E
E
-
-
-
-
P
R
P
R
R
P
E
E
P
E
E
P
E
E
P
E
E
P
E
E
P
E
E
P
-
-
-
-
-
-
-
R
R
R
R
R
-
-
-
-
-
P
P
P
P
P
R
-
-
-
E
E
E
E
-
E
-
-
-
P
-
R
R
R
E
-
E
-
E
-
E
-
E
-
E
-
E
-
P
-
-
-
-
-
-
R
R
R
R
R
R
R
E
-
E
-
E
-
-
-
Ga = Gerentes Área
As = Analista Sistemas
Ap = Analista planejam.
Ou = Outsourcing
E
E
E
P
P
P
P
Legenda Responsabilidade:
R = Responsável
A = Aprova
E = executa
P = Participa
39
Item
Fase/Tarefa
R
H
4.3
Projeto Piloto
4.3.1
Definir o Projeto Piloto
4.3.2
Iniciar o projeto Piloto
4.3.3
Planejar o Projeto Piloto
4.3.4
Executar/Controlar o Projeto Piloto
4.3.5
Obter os Resultados do Piloto
4.3.6
Apresentar os Resultados aos Stakeholders
4.3.7
Encerrar o Projeto Piloto
5
Produção
5.1
Levantar os projetos em andamento
5.2
Definir os Projetos em Andamento
5.3
Planejar Adequação dos Projetos Andamento
6
Encerramento da implantação
6.1
Avaliar os Resultados
6.2
Rever os procedimentos
6.3
Emissão dos Manuais de Gestão de Projetos
6.4
Montar o acervo do projeto
6.5
Obter a aceitação formal do projeto
6.6
Encerramento administrativo
6.7
Encerramento implantação Gestão de Projetos
Legenda Recursos:
RH = RH
TI = TI
Gp = Gerente Projeto
Gc = Gestão Clientes
Ai = Analista Infra
At = Analista tecnologia
Co = Consultor
In = instrutor
Ct =Contratação
Su = suprimento
TI
RECURSOS
Ga Gp Gc As Ai At Ap Co In
P
-
P
-
P
-
R
R
R
R
R
R
E
E
-
E
E
E
R
E
E
E
E
E
-
-
-
-
P
E
E
-
E
E
-
E
E
-
E
-
P
-
P
-
R
R
R
R
R
R
R
E
E
E
E
-
E
E
E
E
-
E
E
E
E
-
Ga = Gerentes Área
As = Analista Sistemas
Ap = Analista planejam.
Ou = Outsourcing
E
Ou Ct
E
-
E
E
-
P
P
P
P
P
-
-
E
-
-
-
E
E
-
R
R
R
P
-
-
-
-
-
-
E
E
P
E
E
P
E
E
P
E
E
P
E
Legenda Responsabilidade:
R = Responsável
A = Aprova
E = executa
P = Participa
2.4.2 OBS – Organization Breakdown Structure
RH
TI
Gerencia
Infra Estrutura
Analista
Infra-estrutura
Gerencia
Sistemas
Analista
Sistemas
Outsourcing
Gerencia
Planejamento
Gerente
Projeto
Analista
Planejamento
Gerencia
Tecnologia
Analista
Tecnologia
Su
Gerencia
clientes
Gestor
Cliente
Consultoria
40
2.5
Plano de Comunicações
2.5.1 Introdução
A Comunicação é uma habilidade vital para o sucesso de qualquer
projeto. Ela é o maior fator isolado capaz de influenciar a qualidade, eficácia,
satisfação e produtividade da equipe do projeto. Uma comunicação efetiva
garante maior clareza das expectativas e papéis da equipe, aumento de
produtividade e qualidade do trabalho, maior colaboração da equipe, melhor
solução de problemas e redução de conflitos.
O plano de comunicação aqui apresentado define a sistemática a
ser usada para o gerenciamento da comunicação durante o desenvolvimento
do projeto. Ele fornece as diretrizes para geração, distribuição, armazenamento
e controle das informações do projeto.
2.5.2 Objetivos do Planejamento da Comunicação
Estabelecer as ligações críticas entre pessoas, idéias e informações que
são necessárias ao projeto.
Orientar todo o processo de comunicação do projeto.
Garantir que todos os envolvidos no projeto terão suas necessidades de
informação atendidas plenamente durante todas as fases do projeto, ou
seja, garantir que as informações serão fornecidas aos interessados, no
tempo, custo, prazo e formato adequado.
Disponibilizar informações de desempenho do projeto através de relatórios
de situação, medições de progresso e previsões.
Formalizar a conclusão de todas as fases do projeto, visando registrar os
resultados de cada fase para formalizar aceitação dos produtos do projeto
pelas pessoas responsáveis.
41
Fazer o encerramento administrativo do projeto, registrando os objetivos
alcançados, as lições aprendidas e uma análise crítica do projeto (sucessos
e insucessos).
2.5.3 Política de Comunicação
A comunicação no projeto será norteada pelos seguintes princípios
básicos:
Clareza e Objetividade
As informações trocadas entre os diversos envolvidos no projeto deverão
ser sempre claras e objetivas. Deve-se focar, sempre, somente nas
necessidades de informação das pessoas evitando-se o excesso de
informações. As análises devem ser resumidas e baseadas em dados e
fatos e não em suposições.
Informatização
A comunicação deve utilizar ao máximo um aplicativo INTRANET
desenvolvido para registro, consolidação e distribuição de todas as
informações
do projeto. Este produto visa manter atualizada toda a
documentação durante o transcorrer do projeto.
Padronização
Toda a comunicação deverá ser registrada em formulários específicos
disponíveis no aplicativo INTRANET.
Democratização/Unicidade da Informação
As informações estarão disponíveis na INTRANET para todos os envolvidos
no projeto na mesma forma e conteúdo.
42
2.5.4 Fluxo de Comunicação
Alta Direção
RH/TI/GA
Mensagem
Clientes
Estil
Gerência
do
Projeto
Técnicas
Apresentação
Técnicas
Reunião
Contratados
Mídi
Técnicos
TI
2.5.5 Habilidades do Gerente de Projeto
Algumas habilidades da administração geral são extremamente
importantes para a atividade de gerenciamento de projeto. Neste sentido, o
Gerente de Projeto deve estar constantemente desenvolvendo as seguintes
habilidades:
43
Comunicação
Promover a comunicação objetiva, clara, coerente e completa entre os
envolvidos no projeto.
Negociação
Promover a discussão entre os interessados no projeto com o objetivo de se
chegar a um acordo.
Liderança
Estabelecer a direção do projeto, alinhar, motivar e inspirar a equipe de modo
a ajudar as pessoas superarem obstáculos e atingirem os objetivos do projeto.
Solução de Problemas
Analisar os problemas para identificar as possíveis alternativas de solução e
decidir pela melhor .
2.5.6 Distribuição das Informações
A distribuição das informações entre os envolvidos no projeto
poderá utilizar-se de vários instrumentos de comunicação existentes na
empresa. Cabe ao gerente de projeto a responsabilidade pela escolha do tipo
adequado de comunicação a ser utilizado na distribuição de cada informação.
A seguir estão apresentados os métodos de comunicação a serem usados no
projeto.
Reunião
É um encontro formal agendado entre pessoas para tratar de assuntos
específicos. Pode ser realizado através de reuniões tradicionais, vídeo
conferências ou tele conferências. Sempre que possível deve ser agendada
com antecedência e a pauta, os participantes, o tempo estimado de
duração, o local e hora da reunião devem ser previamente definidos.
Durante a reunião deverá ser designado o participante responsável pela
44
elaboração da ata da reunião. A ata da reunião deverá ser enviada, no
máximo um dia após a realização da reunião. Os participantes devem
responder/ complementar a ata da reunião, no máximo um dia após o seu
recebimento.
Relatório
São documentos emitidos periodicamente destinados a informar aos
diversos tipos de interessados dados sobre o projeto. Nesta forma de
comunicação estão inclusos todos os tipos de relatórios: gerenciais,
técnicos, de progresso, informativo entre outros. Devem ser claros,
resumidos e objetivos. Sempre que possível deverá utilizar-se de recursos
gráficos (figuras, tabelas, gráficos, diagramas, entre outros) que possam
ilustrar melhor o conteúdo do relatório.
Comunicação escrita
Toda comunicação escrita que registre fatos relevantes ao projeto e que
não possuem formulários padrão específicos, pode ser feita através de
carta, documentos externos, fax, gravura/fotografia, entre outras.
Comunicação verbal
Comunicação informal entre os envolvidos no projeto veiculada através da
fala. Pode ser efetuada através de encontros informais e telefonemas.
Comunicação informatizada
Comunicação formal através de sistemas informatizados entre os
envolvidos no projeto. Pode ser efetuada através do envio/recebimento de
mensagens através do correio eletrônico, INTERNET, INTRANET ,
ferramentas de workflow, entre outras.
Formulário padrão
São formulários previamente definidos a serem utilizados em pontos
específicos e para fins específicos definidos no projeto. Todos os
formulários estarão disponíveis na INTRANET com instruções de uso.
45
2.5.7 Relatório de Performance
O relatório de performance é uma forma de documentar um retrato
completo da situação do projeto. Envolve a coleta e a disseminação de
informações de performance a fim de prover os interessados do projeto com
dados sobre como os recursos estão sendo utilizados para atingir os objetivos
do projeto. Ele trata, principalmente, de informações sobre o escopo,
cronograma, custo e qualidade.
Deverá ser definido um conjunto de informações básicas a serem
distribuídas para os interessados no projeto. A este conjunto de documentos
será dado o nome de Relatório de Progresso. Este relatório engloba
informações de STATUS do projeto – que descreve em que ponto o projeto
está naquela data; de PROGRESSO – que descreve o que já foi obtido pela
equipe do projeto; e de PREVISÃO/PROJEÇÃO – que projeta o status e o
progresso futuros do projeto.
2.5.8 Documentos da Comunicação
Todos os envolvidos no projeto deverão utilizar os formulários
padrão existentes na empresa. Cabe o gerente do projeto o controle e
supervisão do usos destes formulários. Caso se identifique ausência de
formulário padrão para registro de determinada atividade, o gerente do projeto
deverá definir a melhor forma de registro.
46
A seguir serão apresentados os formulários padrão a serem
utilizados no projeto:
Fase
INI
Nome do Formulário Descrição do Formulário
Apresentação
Documento de formato livre contendo uma
descrição sucinta do projeto.
INI
Project Chart
INI
INI
PLI
PLI
PLI
PLI
PLI
PLI
Documento padrão para o registro do project
chart do projeto. Deverá ser preenchido na
reunião de abertura do projeto. Durante o
desenvolvimento do projeto, será usado como
fonte de informação para a tomada de
decisões.
Premissa
Documento padrão para registro das premissas
assumidas para o desenvolvimento do projeto.
Restrição
Documento padrão para registro das restrições
assumidas para o desenvolvimento do
trabalho.
Declaração
de Documento padrão para registro do escopo do
escopo
trabalho.
Matriz de alocação Documento
padrão
para
registro
das
de
responsabilidades de cada membro da equipe
responsabilidades
no projeto.
Matriz de alocação Relatório padrão do Project, exibindo a
de recursos
alocação das pessoas durante as diversas
fases do projeto.
OBS
Documento padrão para registro da estrutura
organizacional do projeto.
Pedido de alteração Documento
padrão
para
registro
das
de escopo
solicitações de alteração de escopo.
Fontes
de Documento padrão para registro das principais
informação
fontes de informação a serem utilizadas no
desenvolvimento
do
projeto
(sistemas,
consultoria, usuários, entre outras).
Legenda:
INI – Iniciação
DPP- Desenvolvimento do Plano do Projeto
PRH- Planejamento de Recursos Humanos
ACT – Aquisições e Contratações
CMT – Customização Metodologias ao PMI
PRD – Produção
ECT – Execução e Controle
ALL – Todas as fases
PLI – Planejamento de Implantação
PLR – Planejamento dos Riscos
PGA – Planejamento da Gestão das Aquisições
CPT – Capacitação
PRP – Projeto Piloto
ENI – Encerramento da Implantação
FIM – Final de Fase
47
Fase
PLI
PLI
ALL
FIM
ALL
ALL
ALL
ALL
Nome do Formulário Descrição do Formulário
Sistemas afetados
Documento padrão para registro dos sistemas
afetados pelo desenvolvimento do projeto. Este
formulário será usado para registras os
sistemas afetados no desenvolvimento do
projeto piloto.
Necessidades
de Documento padrão para registro da infrainfra-estrutura
estrutura necessária para o desenvolvimento
do projeto.
Dúvidas em aberto
Documento padrão para registro das dúvidas
levantadas pela equipe ainda não esclarecidas
Lições aprendidas
Documento padrão para registro das lições
aprendidas em cada fase do projeto. Este
documento deverá conter uma breve avaliação
da execução da fase do projeto levando em
consideração aspectos positivos, aspectos
negativos, pontos a melhorar e sugestões.
Ação corretiva
Documento padrão para registro das ações
corretivas
executadas
durante
o
desenvolvimento do projeto de modo a ajustar
o projeto aos objetivos estabelecidos.
Ação preventiva
Documento padrão para registro das ações
preventivas
executadas
durante
o
desenvolvimento do projeto de modo a
evitar/minimizar problemas futuros.
Melhoria operacional Documento padrão para registro das melhorias
operacionais
implementadas
durante
o
desenvolvimento do projeto.
Decisões de projeto
Documento padrão para registro das decisões
que são tomadas durante o projeto,
descrevendo o cenário, as alternativas
existentes e os fatores que contribuíram para
tomada da decisão.
Legenda:
INI – Iniciação
DPP- Desenvolvimento do Plano do Projeto
PRH – Planejamento de Recursos Humanos
ACT – Aquisições e Contratações
CMT – Customização Metodologias ao PMI
PRD – Produção
ECT – Execução e Controle ALL – Todas as fases
PLI – Planejamento do Implantação
PLR – Planejamento dos Riscos
PGA – Planejamento da Gestão das Aquisições
CPT – Capacitação
PRP – Projeto Piloto
ENI – Encerramento da Implantação
FIM – Final de Fase
48
Fase
ALL
ALL
ALL
PLR,
ECT
PLR,
ECT
Nome do Formulário Descrição do Formulário
Ação imediata
Documento padrão para registro de medidas
que, apesar de não serem essenciais, em
muito podem contribuir para o sucesso do
projeto. Em geral, as ações imediatas são
conduzidas por pessoas que não pertencem à
equipe do projeto, para que o seu cronograma
não seja prejudicado. Contudo, um dos
membros da equipe é sempre designado para
acompanhar o andamento da ação imediata e
relatá-lo aos demais membros.
Demandas
Documento
padrão
para
registro
das
demandas que surgirem ao longo do
desenvolvimento do projeto, que não forem
incluídas no escopo do projeto.
Pendências
Documento padrão para registro das atividades
pendentes que são encontradas durante o
projeto e para facilitar o acompanhamento da
execução das mesmas. Neste documento são,
principalmente registrados os prazo para
eliminação das pendências bem como as
causas que estabeleceram as pendências.
Ficha de controle de Documento padrão para qualificar, quantificar e
risco (I,II e III)
controlar cada um dos riscos identificados.
Ficha de controle de Documento padrão para comunicação da
risco IV
situação dos riscos do projeto.
Legenda:
INI – Iniciação
DPP- Desenvolvimento do Plano do Projeto
PRH – Planejamento de Recursos Humanos
ACT – Aquisições e Contratações
CMT – Customização Metodologias ao PMI
PRD – Produção
ECT – Execução e Controle ALL – Todas as fases
PLI – Planejamento do Implantação
PLR – Planejamento dos Riscos
PGA – Planejamento da Gestão das Aquisições
CPT – Capacitação
PRP – Projeto Piloto
ENI – Encerramento da Implantação
FIM – Final de Fase
49
Fase
ECT
FIM
ALL
ACT
ACT
ACT
ACT
Nome do Formulário Descrição do Formulário
Relatório
de O relatório de progresso é um conjunto de
progresso
informações
estruturadas
em
diversos
documentos consolidados e apresentado de
forma única. Refere-se a um período específico
do projeto. As seguintes informações compõem
o relatório:
Capa
Sumário
Considerações gerais sobre o projeto
Atividades relevantes executadas
Informações técnicas sobre o trabalho
realizado, incluindo informações sobre os
principais quantitativos
Curva ´S´ acumulada com os avanços
físicos e financeiros (previsto, realizado e
tendência)
Situação dos contratos
Cronograma físico
Desembolso financeiro
Termo de aceite
Documento padrão para registro do aceite dos
produtos liberados ao longo do projeto pelas
pessoas pertinentes.
Ata de reunião
Documento padrão para registro dos assuntos
e decisões tratados durante a reunião.
Pedido
de Documento padrão para registro da solicitação
contratação
de contratação de produtos e serviços
Mapa
de Documento padrão para registrar o andamento
Acompanhamento
da solicitação da aquisição de suprimentos
suprimentos
Contrato
preço Contrato padrão para contratação de produtos
global
e serviços a preço global
Acordo de sigilo
Documento padrão para registro do acordo de
sigilo dos dados da empresa.
Legenda:
INI - Iniciação
DPP- Desenvolvimento do Plano do Projeto
PRH - Planejamento de Recursos Humanos
ACT - Aquisições e Contratações
CMT - Customização Metodologias ao PMI
PRD - Produção
ECT - Execução e Controle ALL - Todas as fases
PLI - Planejamento do Implantação
PLR - Planejamento dos Riscos
PGA - Planejamento da Gestão das Aquisições
CPT - Capacitação
PRP – Projeto Piloto
ENI - Encerramento da Implantação
FIM - Final de Fase
50
2.5.9 Controle da Comunicação
Nome do
Formulário
Apresentação
Project Chart
Premissa
Como Emissor
Receptor
Meio
Periodicidade
FP
FP
FP
GE, GA, CT
GA, GP
GA
P/E
P/E
P/E
U
U
U
Restrição
FP
GA
P/E
U
Declaração
de
escopo
Matriz
de
alocação
de
responsabilidades
Matriz
de
alocação
de
recursos
OBS
Pedido
de
alteração
de
escopo
Fontes
de
informação
Sistemas afetados
Necessidades de
infra-estrutura
Lições aprendidas
Ação corretiva
Ação preventiva
Ação imediata
Melhoria
operacional
FP
GA
P/E
U
FP
GP
GE
GP - (E)
GE - (A)
GP - (E)
GE - (A)
GP - (E)
GE - (A)
GP
GA, CT
P/E
U
FP
GP
GA,CT
P/E
Mensal
FP
FP
GP
GP
GA, CT
GE - (A)
GA, CT
P/E
P/E
U
E
FP
GP
CT
P/E
E
FP
FP
GP
GP
CT
GA
P/E
P/E
E
E
FP
FP
FP
FP
FP
GP
GP
GP
GP
GP
CT
CT
CT
CT
CT
P/E
P/E
P/E
P/E
P/E
F
S
S
S
S
Legenda:
COMO: FP - Formulário Padrão
RLT - Relatório
MEIO: P - Papel
E - Eletrônico
Emissor/Receptor: GE - Gerente Geral
GA - Gerente de Área
GP - Gerente Projeto
CT - Corpo Técnico
EX - Externo
Periodicidade:
* Os documentos podem ser alterados, quando necessário.
S - Semanal
Q - Quinzenal
M - Mensal
E - Eventual
F - Final de Fase
U - Única *
51
Nome do
Formulário
Decisões
de
projeto
Demandas
Pendências
Ficha de controle
de risco (I,II e III)
Ficha de controle
de risco IV
Pedido
de
contratação
Contrato
preço
global
Mapa
Acompanhamento
Acordo de sigilo
Como Emissor
Receptor
Meio
Periodicidade
FP
GP
GA, CT
P/E
S
FP
FP
FP
GP
GP
CT
GE
CT
GE, GA, GP
P/E
P/E
P/E
E
S
Q
FP
CT
GP, CT
P/E
Q
FP
GP - (E)
GA - (A)
GP - (E)
GA - (A)
GP - (E)
GA - (A)
GP - (E)
GA - (A)
GP - (E)
GE - (A)
GP
EX
P/E
F
EX
P/E
E
EX
P/E
E
FP
EX
P/E
E
Termo de aceite
FP
GA, GP, CT
P/E
F
GA, GE
P/E
M
P/E
E
FP
FP
Relatório
de FP
progresso
Ata de reunião
FP
Legenda:
COMO: FP - Formulário Padrão
RLT - Relatório
MEIO: P - Papel
E - Eletrônico
Todos
Emissor/Receptor: GE - Gerente Geral
GA - Gerente de Área
GP - Gerente Projeto
CT - Corpo Técnico
EX - Externo
Periodicidade:
* Os documentos podem ser alterados, quando necessário.
S - Semanal
Q - Quinzenal
M - Mensal
E - Eventual
F - Final de Fase
U - Única *
52
2.6
Plano de Gerenciamento de Riscos
A Análise de Risco aplicada à Gerência de Projetos está sendo
usada mais e mais a cada dia, devido ao reconhecimento da importância da
Tecnologia de Informação no sucesso das organizações, contribuindo para o
alcance de seus objetivos.
O entendimento da necessidade de alinhamento entre os Sistemas
de Informação e os negócios da organização e a grande quantidade de
projetos mal sucedidos ou cancelados ou não confiáveis ou entregues fora do
prazo ou que não atendem aos requisitos (estes são a maioria) levaram as
empresas a buscar alternativas para este problema. Isto sem considerar o
custo de oportunidade perdida, que é muito maior, pois é difícil mensurar o
custo de perda de mercado por causa dos problemas citados acima.
A alternativa mais eficiente, e que foi quantificada nos últimos anos,
é a Análise ou Gerência de Riscos. Há estudos que comprovam que projetos
que se utilizaram desta técnica foram entregues antes do prazo e com custo
menor.
É importante, contudo, distinguir onde esta análise pode e onde não
pode ajudar. A Análise de Risco não transforma um ambiente adverso, nem
gera recursos. Porém, se não realizada, as chances de um projeto não ser
bem sucedido aumenta sensivelmente.
Entendemos risco como sendo a probabilidade de que qualquer
variável associada a um projeto possa assumir valores, dentro de sua
distribuição normal de valores, que possam diminuir, ou eliminar por completo,
as chances de sucesso do projeto.
Em todo projeto, devido às suas características de ser um
empreendimento temporário com o objetivo de criar um produto ou serviço
único, há riscos implícitos e explícitos.
53
Por outro lado, podemos afirmar que um Projeto é um problema
"esquedulado" para solução.
A título de melhor esclarecimento, citamos alguns exemplos de
fatores de risco comuns à maioria dos projetos:
Flutuação na taxa de câmbio ou juros;
Introdução de novos produtos ou serviço no mercado;
Patrocínio para o projeto dentro e fora da organização;
Experiência, competência e tamanho da equipe de projeto;
Os riscos originam-se, na realidade, das incertezas que cercam os
projetos. Os projetos estão repletos de incertezas, tais como:
Os objetivos estão bem definidos?
O apoio político dentro da empresa é suficiente?
Existem produtos chegando ao mercado que colocam em perigo o
projeto?
Os recursos financeiros e não financeiros são suficientes?
A equipe do projeto está adequadamente treinada?
A equipe é experiente o suficiente?
Os prazos de entrega são realistas?
O fluxo de caixa do projeto é adequado?
Há pendências legais?
54
Para melhor lidar com os riscos, a metodologia PMI (PMI, 2004)
propõe o que chamamos de Gerência dos Riscos do projeto; este
gerenciamento inclui os processos que visam à maximização dos resultados de
eventos positivos e minimização das conseqüências de eventos negativos. A
Gerência de Riscos compõe-se dos seguintes processos principais:
Identificação
Acompanhamento
Process
o
Análise
Planejamento
Identificação dos riscos: determinar quais os riscos são os mais prováveis
de afetar o projeto e documentar as características de cada um; Os passos
necessários são:
Identificação dos Stakeholders (pessoas, grupos ou organizações,
envolvidos ativamente no projeto que podem ganhar ou perder - poder
e/ou dinheiro - com o resultado do projeto;
Lista de Fatores de Risco;
Brainstorm;
Quantificação dos Riscos: avaliar os riscos e suas interações no sentido
de avaliar possíveis conseqüências; Os passos necessários são:
Impacto de fatores de risco sobre o projeto;
Priorização de fatores de risco;
55
Desenvolvimento de Respostas aos Riscos: definir as melhorias
necessárias para o aproveitamento de oportunidades e respostas às
ameaças; Os passos necessários são:
Atribuição de responsabilidades;
Plano de contenção (redução do risco);
Planos de contingência (diminuir o estrago);
Controle das Respostas aos Riscos: responder às mudanças nos riscos
no decorrer do projeto; Os passos necessários são:
Monitoramento do fator de risco;
Acionamento dos planos de contenção e contingência;
2.6.1 Identificação dos Riscos do projeto
2.6.1.1
FATORES CRÍTICOS DE SUCESSO PARA A IDENTIFICAÇÃO
DOS RISCOS
2.6.1.1.1 CONSCIENTIZAÇÃO DO CORPO GERENCIAL
O uso da Gerência de Riscos ainda é exceção e não regra, devido a
fatores pessoais e culturais. Muitos gerentes vêem-se como sendo a
personificação da Análise de Risco e acreditam então que qualquer processo
formal de Análise de Risco é um overhead desnecessário. Outros acreditam
não haver risco em seus projetos, não havendo outra alternativa além do êxito.
Outros recusam-se a admitir risco em seus projetos (admitem apenas no
projeto dos outros), pois em sua concepção, admitir riscos é perder o controle.
Outros aceitam haver riscos em seus projetos, mas afirmam que eles nunca
ocorrerão. Outros não conseguem ver o benefício de usar recursos escassos
analisando coisas que podem não ocorrer e gastam mais recursos nas coisas
que efetivamente acontecem: ao invés de olhar para os riscos, porque não
gastar recursos no próprio projeto, indagam estes.
56
2.6.1.1.2 CULTURA DAS ORGANIZAÇÕES
A cultura das organizações também pode inibir o uso da Análise de
Risco, pois em muitas organizações, o gerenciamento da crise é mais
valorizado que a Análise de Risco, sendo a alternativa para estas crises,
trabalhar duro e acreditar no projeto. Isto, porque acreditam que com verba
todos os riscos são evitados. Além disto, a preocupação em que, ao admitir
haver riscos no projeto, o mesmo ser investigado, tornar-se público e isto
contar negativamente para seus gerentes.
Outro fator é a indicação de riscos com os fornecedores e estes
sempre são usados como o motivo para os projetos entregues com atraso e
acima do orçamento.
A forma mais eficiente de entender a importância do uso da Análise
de Risco é que quanto mais projetos que a usam forem bem sucedidos, a
rejeição tende a diminuir.
2.6.1.1.3 DEDICAÇÃO
DE
RECURSOS
ADEQUADOS
NA
IDENTIFICAÇÃO DOS RISCOS
Além de adotar uma Análise de Riscos, não basta dedicar uma ou
duas horas semanais criando listas com os dez principais riscos e elaborar um
plano para contê-los. Isto pode ser admitido para projetos de curta duração,
mas não para projetos mais complexos. A Análise de Risco é trabalho pesado,
englobando entender detalhadamente cada risco, o seu relacionamento com
os objetivos do projeto, as restrições e tudo o mais que for indefinido e vago.
Outro fator é não subestimar a quantidade e a importância dos
fatores de risco, em especial o alto impacto no projeto de uma grande
quantidade de riscos de baixo impacto.
57
2.6.1.2
PLANO DE TRABALHO PARA A IDENTIFICAÇÃO DOS RISCOS
Considerando os fatores expostos acima, a identificação dos riscos
será feita com o apoio de consultores especialistas e utilização de
questionários de diagnose de risco (KAROLAK, 2006), bem como reuniões de
brainstorm. Os questionários e reuniões de brainstorm serão realizados em
todos os níveis do projeto, não apenas no nível gerencial, pois a sua
disseminação por toda a equipe é essencial, sendo para isto necessário o
treinamento de toda a equipe do projeto, enfatizando mais a comunicação do
que a avaliação do risco.
Exemplos de perguntas de questionários de identificação de riscos:
Seus gerentes de projeto são:
0 - Pouco experientes
5 - Experientes
10 - Muito experientes
Sua equipe já desenvolveu projetos semelhantes?
0 - Não
5 - Uma única vez
10 - Muitas vezes
O processo de documentação a ser adotado no projeto é:
0 - Nenhum
5 - Informal
10 – Formal
O nível de confiança da equipe no sucesso do projeto é:
0 - Baixo
5 - Médio
10 - Alto
A Gerência de Risco identifica o que diferencia um projeto dos
demais. Assim, ninguém externo ao projeto tem condições de identificar seus
riscos. Ao contrário, a partir da troca de informações entre os envolvidos em
todos os níveis do projeto é que se conseguirá esta identificação. Assim, a
58
comunicação aberta em todos os níveis é fundamental para a Gerência de
Riscos
2.6.1.3
IDENTIFICAÇÃO DOS STAKEHOLDERS
Principais Stakeholders:
Executivo patrocinador:
RH – Gerente da Área de RH;
Cliente:
TI – Gerente da Área de TI;
Gerente do Projeto:
A ser designado;
Equipe do Projeto:
A ser designada,
2.6.1.4
LISTA DOS FATORES DE RISCOS
Foram
identificados
os
seguintes riscos para o Projeto e
classificados em três categorias:
Categoria 1: Riscos eliminados através de ações específicas:
Riscos:
Solvência de empresas contratadas para Consultoria
Solvência de empresas contratadas para Treinamento
Solvência de empresas contratadas para o Projeto Piloto
Ação realizada para eliminação dos riscos:
Checagem da solidez das empresas (análise dos Balanços Econômicos
e Financeiros dos 3 últimos exercícios fiscais) e consulta aos clientes
atuais;
Colocação de empresas backup para as atividades contratadas;
Risco:
59
Atraso na entrega de Ferramentas e softwares adquiridos (processo de
importação)
Ação realizada para eliminação dos riscos:
Pesquisar o prazo médio de entrega e considerar no processo de
compra uma folga de tempo com relação ao prazo médio de entrega;
Risco:
Falta, doenças, acidentes, morte em família de membros da equipe do
projeto
Ação realizada para eliminação dos riscos:
Indicação de participantes backups para a equipe do projeto, os quais
serão permanentemente informados sobre os trabalhos realizados;
Risco:
Experiência, competência e tamanho da equipe do projeto;
Ação realizada para eliminação dos riscos:
Escolha de consultores experientes em PMI e nivelamento da equipe do
projeto nas ferramentas e técnicas utilizadas na Gestão de Projetos;
Risco:
Flutuação das taxas de câmbio entre o Real e o Dólar;
Ação realizada para eliminação dos riscos:
Todas as contratações e aquisições serão realizadas em Real, através
de representantes nacionais de produtos estrangeiros; se a empresa for
uma empresa exportadora, a maioria de suas receitas serão em Dólar, o
que significa que uma desvalorização do Real frente ao Dólar não
representa um risco; apenas a desvalorização do Dólar frente ao Real
(cuja probabilidade de ocorrência é bem menor) acarretará um maior
desembolso da Companhia;
60
Risco:
Flutuação das taxas de juros;
Ação realizada para eliminação dos riscos:
Todas
as
contratações
e
aquisições
serão
realizadas
sem
financiamento, com o pagamento a 30 dias após a entrega ou término
dos serviços; para serviços que tenham duração acima de 2 meses,
será elaborado um plano de pagamento mensal, sem a inclusão de
taxas de juros;
Categoria 2: Riscos a aceitar, pois para os quais não há formas de mitigação
ou eliminação devido a fatores que não estão dentro do controle do projeto:
Riscos:
Motivos de força maior (greves, catástrofes, etc.);
Reestruturação da empresa;
Situação econômica e financeira da empresa;
Mudança Gerencial na Diretoria sob a qual a TI estiver subordinada;
Reestruturação da Área de TI;
Categoria 3: Riscos a serem quantificados, e para os quais serão traçadas
formas de mitigação (planos de contenção e de contingência):
Mudança Gerencial na Área de TI;
Iniciação de outro Projeto prioritário para a Companhia ou para uma
outra Diretoria da Companhia, sob a qual a área de TI não esteja
subordinada;
Execução orçamentária acima do previsto (gastos com consultoria,
treinamento, software, etc.);
Ausência de parte da equipe;
61
Entrega das ferramentas e softwares necessários (importação);
Prazo do projeto acima do previsto (controle do caminho crítico);
Produtos
entregues
fora
dos
padrões
determinados
(não
conformidades);
Envolvimento dos Stakeholders;
Surgimento de outras metodologias para Gerenciamento de Projetos
concorrentes ao PMI;
Indisponibilidade dos Gerentes de Projeto da área de TI na avaliação
de quais projetos em andamento serão adaptados ao PMI;
Indisponibilidade dos técnicos da área de TI no treinamento em PMI;
Comprometimentos dos Gerentes de Projeto da área de TI, na
implantação;
Comprometimento
implantação;
dos
terceiros
(contratados)
envolvidos,
na
62
2.6.2 Quantificação dos riscos
Para este processo, será utilizada a Ficha de Controle de Risco I
(ALENCAR, 2008):
Identificação:
Ficha de Controle de Risco I
Incerteza:
(↓) Impacto x Probabilidade (→)
VHi
Hi
Med
Descrição:
Lo
VLo
Nil
Nil
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
Responsável:
$ → Custo T → Tempo
P → Político
Origem:
L → Legal C →
Q → Qualidade
Comercial
Criada em
Para cada risco identificado, a probabilidade de ocorrência do
mesmo será definida entre os valores Vhi, Hi, Med, Lo, Vlo e Nil. E será
definido o impacto para cada uma das dimensões de risco (curso, tempo,
político, legal, comercial e qualidade), utilizando a mesma escala de valores. A
partir destas definições, preenche-se a ficha, colocando-se os símbolos de
cada dimensão do risco no respectivo cruzamento da probabilidade (linha) com
o impacto (coluna).
63
Exemplo de Ficha de Controle de Risco I preenchida:
Identificação: ABC 23
Ficha de Controle de Risco I
(↓) Impacto x Probabilidade (→)
VHi
Hi
Med
Lo
VLo
Nil
T,P
$
Q
L,C
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Nil
Criada em
03/02/10
Incerteza: Nível de experiência da equipe com
X Windows.
Descrição: devido a nossa falta de experiência
com X Windows, é possível que não nos seja
possível completar a codificação da interface
gráfica dentro do prazo e o código não tenha a
qualidade que necessitamos.
Responsável: William Albuquerque
Origem: Antonio Alencar
Visando a apoiar o trabalho de definição dos fatores de escala de
forma uniforme entre todos os envolvidos, será utilizada a seguinte atribuição
de significado para a escala de valores:
Impacto Sobre o Projeto
Fatores
de Escala
Prob.
VHi
Hi
Med
Lo
VLo
Nil
> 70%
50-70%
30-50%
10-30%
1-10%
0-1%
Atraso Aumento Falha Atingir Critérios
(semanas) de Custo
de Qualidade
>6
4-6
3-4
2-3
1-2
0
> 30%
15-30%
10-15%
5-10%
0-5%
0%
Essenciais
Muito Importantes
Importantes
Pouco Importantes
Sem Importância
Nenhum
64
Após o preenchimento da Ficha de Controle de Risco I para cada
um dos riscos identificados, os mesmos serão categorizados por impacto
absoluto de acordo a seguinte escala:
Escala
VHi
Hi
Med
Lo
VLo
Nil
Pesos
Probabilidade
0,9
0,7
0,5
0,3
0,1
0
Impacto
0,8
0,4
0,2
0,1
0,05
0
Risco XXXXX
Político 0,000
Tempo 0,000
Comercial 0,000
Custo 0,000
Qualidade 0,000
Legal 0,000
Total 0,000
+
Para obter o valor cada dimensão, multiplica-se a probabilidade pelo
impacto. O impacto absoluto é o somatório dos valores de todas as dimensões.
Exemplo de cálculo de impacto absoluto:
Escala
VHi
Hi
Med
Lo
VLo
Nil
Pesos
Probabilidade Impacto
0,9
0,8
0,7
0,4
0,5
0,2
0,3
0,1
0,1
0,05
0
0
Risco ABC 23
Político 0,280
Tempo 0,280
Custo 0,140
+
Qualidade 0,070
Comercial 0,000
Legal 0,000
Total 0,770
Com isto, tem-se uma categorização pela posição relativa de todos
os riscos identificados:
1
2
3
4
5
6
7
8
Risco
XKL 34
HGT 96
JGT 12
GTF 87
LKB 09
ABC 23
SDT 38
GDR 22
Relevância
1,245
1,200
1,100
1,000
0,900
0,770
0,500
0,400
65
R001 - Mudança Gerencial na Área de TI;
Identificação: R001
VHi
Hi
Med
Lo
VLo
Nil
Ficha de Controle de Risco I
Criada em
DD/MM/AA
Incerteza: Mudança Gerencial na Área de TI
(↓) Impacto x Probabilidade (→)
P
T,C
Nil
VLo
Q
$
L
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Descrição: Caso haja mudanças gerenciais na
TI, o(s) novo(s) gerente(s) devem ser
posicionados do andamento e benefícios do
projeto, visando a manter na equipe do projeto
o(s) empregados de sua(s) gerência(s)
alocado(s) no mesmo
Responsável: a ser designado
Origem: a ser identificado
Risco R001
Político 0,240
Tempo 0,120
Comercial 0,120
Custo 0,015
Qualidade 0,030
Legal 0,000
Total 0,525
+
66
R002 - Iniciação de outro Projeto prioritário para a Companhia ou para uma
outra Diretoria da Companhia, sob a qual a área de TI não esteja
subordinada;
Identificação: R002
VHi
Hi
Med
Lo
VLo
Nil
Ficha de Controle de Risco I
(↓) Impacto x Probabilidade (→)
P,Q
$,T
C
Nil
VLo
Lo
Dimensões de
$ → Custo T → Tempo
L → Legal C →
Comercial
L
Med
Hi
VHi
Risco
P → Político
Q → Qualidade
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Criada em
DD/MM/AA
Incerteza: Iniciação de outro Projeto
prioritário para a Companhia ou para uma
outra Diretoria da Companhia, sob a qual a
área de TI não esteja subordinada
Descrição: Um projeto prioritário para a
empresa pode vir a necessitar da alocação de
parte da equipe, principalmente se a área
solicitante não for da mesma Diretoria sob a
qual a área de TI esteja subordinada
Responsável: a ser designado
Origem: a ser identificado
Risco R002
Político 0,560
Tempo 0,280
Comercial 0,070
Custo 0,280
Qualidade 0,560
Legal 0,000
Total 1,750
+
67
R003 - Execução orçamentária acima do previsto (gastos com consultoria,
treinamento, software, etc.);
Identificação: R003
Ficha de Controle de Risco I
(↓) Impacto x Probabilidade (→)
P,$,
C
T,Q
L
VHi
Hi
Med
Lo
VLo
Nil
Nil
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Criada em
DD/MM/AA
Incerteza: Execução orçamentária acima do
previsto (gastos com consultoria,
treinamento, software,etc)
Descrição: O orçamento do projeto foi feito,
programado e aprovado pela Diretoria; a
execução acima do previsto, acarretará a
necessidade de aprovação de verba
extraordinária, além de prejudicar a imagem do
Projeto
Responsável: a ser designado
Origem: a ser identificado
Risco R003
Político 0,720
Tempo 0,360
Comercial 0,720
Custo 0,720
Qualidade 0,360
Legal 0,180
Total 3,060
+
68
R004 - Ausência de parte da equipe;
Identificação: R004
VHi
Hi
Med
Lo
VLo
Nil
Ficha de Controle de Risco I
(↓) Impacto x Probabilidade (→)
T,Q
P,$
C
L
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Nil
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Criada em
DD/MM/AA
Incerteza: Ausência de parte da equipe
Descrição: Caso parte da equipe se ausente,
o trabalho de algumas atividades que estejam
no caminho crítico podem sofrer atraso e, por
conseguinte, o projeto também sofrerá atraso
Responsável: a ser designado
Origem: a ser identificado
Risco R004
Político 0,200
Tempo 0,400
Comercial 0,050
Custo 0,200
Qualidade 0,400
Legal 0,000
Total 1,250
+
69
R005 - Entrega das ferramentas e softwares necessários (importação);
Identificação: R005
Ficha de Controle de Risco I
(↓) Impacto x Probabilidade (→)
VHi
Hi
Med
Lo
VLo
Nil
T
$,L
C
Q,P
Nil
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Criada em
DD/MM/AA
Incerteza: Entrega das ferramentas e
softwares necessários (importação)
Descrição: A indisponibilidade das
ferramentas e softwares pode incorrer em
atraso nas atividades do projeto, bem como
custo extra de consultoria
Responsável: a ser designado
Origem: a ser identificado
Risco R005
Político 0,015
Tempo 0,120
Comercial 0,030
Custo 0,060
Qualidade 0,015
Legal 0,060
Total 0,300
+
70
R006 - Prazo do projeto acima do previsto (controle do caminho crítico);
Identificação: R006
Ficha de Controle de Risco I
(↓) Impacto x Probabilidade (→)
P,T,
C
$,Q,
L
VHi
Hi
Med
Lo
VLo
Nil
Nil
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Criada em
DD/MM/AA
Incerteza: Prazo do projeto acima do previsto
(controle do caminho crítico)
Descrição: O controle do prazo do projeto é
muito importante, pois qualquer atraso pode vir
a impactar a liberação de recursos humanos
planejados para outros projetos, além de
retardar a implantação do PMI na área de TI
Responsável: a ser designado
Origem: a ser identificado
Risco R006
Político 0,720
Tempo 0,720
Comercial 0,720
Custo 0,360
Qualidade 0,360
Legal 0,360
Total 3,240
+
71
R007 - Produtos entregues fora dos padrões determinados (não
conformidade);
Identificação: R007
Ficha de Controle de Risco I
(↓) Impacto x Probabilidade (→)
Q,P,
$,T
C,L
VHi
Hi
Med
Lo
VLo
Nil
Criada em
DD/MM/AA
Incerteza: Produtos entregues fora dos
padrões determinados (não-conformidades)
Descrição: As Não-conformidades significam
retrabalho, aumento de custo e aumento de
prazo
Nil
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Responsável: a ser designado
Origem: a ser identificado
Risco R007
Político 0,720
Tempo 0,720
Comercial 0,360
Custo 0,720
Qualidade 0,720
Legal 0,360
Total 3,600
+
72
R008 - Envolvimento dos Stakeholders;
Identificação: R008
Ficha de Controle de Risco I
(↓) Impacto x Probabilidade (→)
VHi
Hi
Med
Lo
VLo
Nil
P
$,T
C
L,Q
Nil
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Criada em
DD/MM/AA
Incerteza: Envolvimento dos Stakeholders
Descrição: Um baixo envolvimento dos
Stakeholders prejudica a sucesso do projeto,
podendo inclusive implicar em seu
cancelamento. Como o patrocinador é a
própria área de RH, este risco é muito baixo
Responsável: a ser designado
Origem: a ser identificado
Risco R008
Político 0,020
Tempo 0,010
Comercial 0,005
Custo 0,010
Qualidade 0,000
Legal 0,000
Total 0,045
+
73
R009 - Surgimento de outras metodologias para Gerenciamento de Projetos
concorrentes ao PMI;
Identificação: R009
Ficha de Controle de Risco I
Criada em
DD/MM/AA
Incerteza: Surgimento de outras
metodologias para Gerenciamento de
Projetos concorrentes ao PMI
(↓) Impacto x Probabilidade (→)
VHi
Hi
Med
Lo
VLo
Nil
$,T
P,C
Nil
L,Q
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Descrição: Se alguma outra metodologia para
Gestão de Projetos for avaliada como mais
eficiente que o PMI, o projeto pode vir a ser
cancelado. Como a maturação deste tipo de
metodologia é demorada e o PMI tem-se
mostrado eficiente, entendemos ser este risco
muito baixo
Responsável: a ser designado
Origem: a ser identificado
Risco R009
Político 0,020
Tempo 0,040
Comercial 0,020
Custo 0,040
Qualidade 0,000
Legal 0,000
Total 0,120
+
74
R010 - Indisponibilidade dos Gerentes de Projeto da área de TI na
avaliação de quais projetos em andamento serão adaptados ao PMI;
Identificação: R010
VHi
Hi
Med
Lo
VLo
Nil
Ficha de Controle de Risco I
(↓) Impacto x Probabilidade (→)
T
$,Q
P,C
Nil
L
Hi
VLo
Lo
Med
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Criada em
DD/MM/AA
Incerteza: Indisponibilidade dos Gerentes de
Projeto da área de TI na avaliação de quais
projetos em andamento devem ser
adaptados ao PMI
Descrição: A adequação de projetos em
andamento ao PMI é de vital importância para
a implantação desta metodologia. O papel do
gerentes destes projetos é essencial para o
alcance deste objetivo
Responsável: a ser designado
Origem: a ser identificado
Risco R010
Político 0,140
Tempo 0,560
Comercial 0,140
Custo 0,280
Qualidade 0,280
Legal 0,000
Total 1,400
+
75
R011 - Indisponibilidade dos técnicos da área de TI no treinamento em PMI;
Identificação: R011
VHi
Hi
Med
Lo
VLo
Nil
Ficha de Controle de Risco I
(↓) Impacto x Probabilidade (→)
$
T,Q
C
P
L
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Nil
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Criada em
DD/MM/AA
Incerteza: Indisponibilidade dos técnicos da
área de TI no treinamento em PMI
Descrição: O treinamento dos técnicos da
área de TI na metodologia PMI é muito
importante, pois são eles que fazem a gestão
dos projetos na área de TI
Responsável: a ser designado
Origem: a ser identificado
Risco R011
Político 0,070
Tempo 0,280
Comercial 0,140
Custo 0,560
Qualidade 0,280
Legal 0,000
Total 1,330
+
76
R012 - Comprometimentos dos Gerentes de Projeto da área de TI, na
implantação;
Identificação: R012
Ficha de Controle de Risco I
(↓) Impacto x Probabilidade (→)
VHi
Hi
Med
Lo
VLo
Nil
T,$
Q,C
P
L
Nil
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Criada em
DD/MM/AA
Incerteza: Comprometimentos dos Gerentes
de Projeto da área de TI na implantação
Descrição: A participação dos Gerentes de
Projeto, garantindo a adequação dos projetos
em andamento sob sua responsabilidade e
avaliados como fundamentais a serem
adequados ao PMI, é de extrema relevância
Responsável: a ser designado
Origem: a ser identificado
Risco R012
Político 0,070
Tempo 0,280
Comercial 0,140
Custo 0,280
Qualidade 0,140
Legal 0,035
Total 0,945
+
77
R013 - Comprometimento dos terceiros (contratados) envolvidos, na
implantação;
Identificação: R013
VHi
Hi
Ficha de Controle de Risco I
Criada em
DD/MM/AA
Incerteza: Comprometimento dos terceiros
(contratados) envolvidos, na implantação
(↓) Impacto x Probabilidade (→)
Q
T,$,
L
Med
Lo
VLo
Nil
P
C
Nil
VLo
Lo
Med
Hi
VHi
Dimensões de Risco
$ → Custo T → Tempo
P → Político
L → Legal C →
Q → Qualidade
Comercial
Pesos
Escala Probabilidade Impacto
VHi
0,9
0,8
Hi
0,7
0,4
Med
0,5
0,2
Lo
0,3
0,1
VLo
0,1
0,05
Nil
0
0
Categorização
identificados:
1
2
3
4
5
6
7
8
9
10
11
12
13
Risco
R007
R006
R003
R002
R010
R011
R004
R013
R012
R001
R005
R009
R008
pela
posição
Relevância
3.600
3.240
3.060
1.750
1.400
1.330
1.250
1.075
0.945
0.525
0.300
0.120
0.045
Descrição: A execução dos projetos da área
de TI pode ser em sua maior parte terceirizada.
O comprometimento dos terceiros envolvidos
nos projetos em andamento é de suma
importância para a implantação o PMI na área
de TI
Responsável: a ser designado
Origem: a ser identificado
Risco R013
Político 0,050
Tempo 0,200
Comercial 0,025
Custo 0,200
Qualidade 0,400
Legal 0,200
Total 1,075
relativa
de
+
todos
os
riscos
78
Além da categorização, que apresenta o impacto absoluto de cada
risco, utilizaremos a seguinte tabela para priorização das dimensões individuais
Impacto
de cada um dos riscos a serem minimizados:
VHi
Hi
Med
Lo
VLo
Nil
Nil
0,045
0,035
0,025
0,015
0,005
VLo
0,090
0,180
0,070
0,140
0,050
0,100
0,030
0,060
0,010
0,020
Lo
Med
Probabilidade
0,360
0,280
0,200
0,120
0,040
Hi
Precisam de Atenção
Críticos
Irrelevantes
Lantentes
0,720
0,560
0,400
0,240
0,080
VHi
79
2.6.3 Plano de Gerenciamento de Riscos
2.6.3.1
DESENVOLVIMENTO DE RESPOSTAS AOS RISCOS
Para este processo será utilizada a seguinte Ficha de Controle de Risco
II:
Ficha de Controle de Risco II
Contexto:
Estratégia de Contenção:
1.
2.
3.
4.
Plano de Contingência:
Disparar Plano de Contingência:
Observação: nesta ficha de controle de risco não é necessária a indicação do
Código do Risco, pois as fichas de controle de risco serão elaboradas
seqüencialmente (Fichas I, II e III) para cada risco.
80
Exemplo de Ficha de Controle de Risco II preenchida:
Ficha de Controle de Risco II
Contexto: apesar da interface gráfica ser uma parte crucial do sistema, nós não temos ninguém
habilitado a usar o X Windows. Todos os integrantes do projeto estão estudando X Windows,
entretanto só uma pessoa possui alguma experiência significativa com interfaces gráfica (em um
tipo de sistema completamente diferente. Existem outras pessoas na empresa com experiência
relevante nesta área, porém é provável que eles não estejam disponíveis para trabalhar neste
projeto.
Estratégia de Contenção:
1. Atualizar as estimativas de tempo de codificação e teste de forma a refletir a necessidade de
treinamento em X Windows (feito em 1/5/10).
2. Obter aprovação do cliente para o aumento nas estimativas de tempo de codificação e teste
(obtido em 6/6/10).
3. Conseguir que um especialista em X Windows seja alocado ao projeto (feito em 10/6/10).
4. Contratar uma empresa especializada em X Windows para treinar nosso pessoal
(contratada em (30/7/10)
Plano de Contingência: subcontratar o desenvolvimento da interface gráfica. Estima-se que o
aumento de custo do projeto seja de $25.000,00.
Disparar Plano de Contingência: se um especialista em X Windows não tiver sido alocado ao
projeto até 30/7/10
O preenchimento desta ficha para cada um dos riscos será feita pelo
respectivo responsável (vide Ficha de Controle de Risco I) no início da
execução do projeto e revisada ao longo do mesmo.
81
2.6.3.2
CONTROLE DAS RESPOSTAS AOS RISCOS
Para este processo será utilizada a seguinte Ficha de Controle de Risco III:
Ficha de Controle de Risco III
Histórico
Conclusão:
Data
Data de
Conclusão:
Observação: nesta ficha de controle de risco não é necessária a indicação do
Código do Risco, pois as fichas de controle de risco serão elaboradas
seqüencialmente (Fichas I, II e III) para cada risco.
Exemplo de Ficha de Controle de Risco III preenchida:
Ficha de Controle de Risco III
Histórico
Data
Estimativas de custo revisadas. Estima-se um atraso de 3 semanas o na entrega da
30/1/10
interface gráfica.
Cliente aprova as novas estimativas de tempo de codificação e teste.
13/1/10
Eduardo Silva está sendo alocado ao projeto a partir de 6/5/10 para cuidar das
1/6/10
atividades de controle de qualidade, treinamento e programação em X Windows.
Treinamento em X Windows finalizado.
15/7/10
50% do código escrito e testado. Estamos 1 semana a frente dos prazos
15/9/10
estipulados
13/11/10
100% do código escrito e testado.
30/1/11
Interface gráfica entregue no prazo.
Conclusão: código entregue no prazo. Cliente deu o aceite para a
Data de
interface gráfica.
Conclusão:
15/2/11
O preenchimento desta ficha para cada um dos riscos será feita pelo
respectivo responsável (vide Ficha de Controle de Risco I) durante a execução
do projeto, para acervo (juntamente com as outras fichas) e consulta pelas
equipes dos novos projetos (lições aprendidas).
82
Quinzenalmente será apresentada a situação dos riscos do projeto, através da Ficha de Controle de Risco IV:
Risco (evento)
Aplicabilid Impacto
ade
Fases Tipo de Respost
onde o resposta a ao
evento
risco
pode
ocorrer
Severidade
Probabili
dade de
ocorrênc
ia
83
Exemplo de Ficha de Controle de Risco IV preenchida:
Fonte
de
Risco
Risco (evento)
Aplicabili Exemplos
dade
Impac Fases
to
onde o
evento
pode
ocorrer
Tipo Resposta ao risco
de
respo
sta
Alocaç
ão de
pessoa
s
Pessoas que
foram alocadas
para o projeto não
estão disponíveis
no momento em
que se tornam
necessárias.
Aplicável
a
qualquer
projeto.
Produ Todas
tivida
de
(praz
oe
custo)
Aceit
ável
sem
plano
de
contin
gênci
a
A empresa aceita a
seguinte ação: Obter
novos recursos e/ou
renegociar o
cronograma de
alocação de recursos.
O prazo do projeto
também deve ser
alterado.
Alta
Alta
Prazo Todas
Aceit
ável
sem
plano
de
contin
gênci
a
A empresa aceita a
seguinte ação: Obter
novos recursos e/ou
renegociar o
cronograma de
alocação de recursos.
O prazo do projeto
também deve ser
alterado.
Alta
Modera
da
1) Durante o projeto,
algumas pessoas não
conseguem cumprir o
cronograma de
alocação de recursos
que foi negociado ao
final da fase de
planejamento, pois
estão
sobrecarregadas.
Alocaç Atraso no
Aplicável 1) Demora no início
ão de cronograma
a
de uma fase do
pessoa provoca
qualquer projeto invalida o
s
realocação de
projeto. cronograma de
pessoas para
alocação de recursos
datas em que elas
que foi negociado ao
não estão
final da fase de
planejamento. Nova
disponíveis.
negociação deve
ocorrer.
Severid Probabi
ade
lidade
de
ocorrên
cia
84
2.7
Plano de Contratações
O Planejamento das Contratações do Projeto inclui os processos
necessários para obtenção de bens e serviços externos à organização.
São eles:
Planejamento da Contratação;
Preparação das Solicitações;
Obtenção de Propostas;
Seleção de Fornecedores;
Administração dos Contratos;
Encerramento dos Contratos.
Para a Implantação da Gestão de Projetos na Área de TI será
utilizada a estrutura funcional e apoio existente na empresa, quer seja, no
tocante a recursos humanos, materiais, ou logística, etc.
Serão contratados consultores especialistas na metodologia PMI e
software específico de gestão de projetos e o treinamento na utilização do
software. Para tais contratações a equipe do projeto terá o apoio da Gerência
de Contratações.
2.7.1 Tipos de contrato que serão firmados
A necessidade de contratação externa se restringirá ao consultor
especializado na Metodologia de Gerenciamento de Projetos (PMI), ao
Software e ao Treinamento da ferramenta de Gerenciamento de Projetos.
85
Tais contratações serão feitas pela Gerência de Contratações, na
ocasião prevista no cronograma e de acordo com os critérios de qualificações
estabelecidas pela equipe de Implantação da Metodologia, e observando os
requisitos básicos de contratação citado nos critérios de qualificação a serem
considerados no processo de contratação.
A contratação da consultoria especializada e o treinamento nas
ferramentas de gestão de projeto deverão atender ao prazo definido no
cronograma e o tipo de contrato a ser firmado será o de serviços remunerados
a preço Global, levando-se em conta o prazo aproximado de 6 meses para a
implantação desta Metodologia.
Critérios de qualificações a serem considerados no processo de
Contratação
Na contratação do Consultor da metodologia PMI, deverá ser
observado os seguintes requisitos:
Consultor deverá ser certificado PMI – Project Management Institute;
Consultor deverá ter experiência comprovada após a certificação do PMI no
mínimo de 2 anos.
Na contratação do Treinamento do Software:
Treinamento deverá ser ministrado nas dependências da empresa;
Instrutor deverá ser especialista e certificado na ferramenta;
Treinamento
deverá
obedecer
às
datas
estabelecidas
conforme
cronograma agendado.
Para todas as contratações deverão ser observadas todas as normas que
regulamentam o serviço de contratação estabelecido pela Gerência de
Contratação.
Além disto, para cada um dos pacotes de contratação a equipe de
implantação
descreverá
os
serviços
compreendidos,
seus
principais
86
quantitativos, a sua programação, e os limites de responsabilidade para a
assinatura de contratos e ordens de compra.
No caso da aquisição do software, a área de controle de software da
gerência de informática, emitirá o documento “Mapa de Acompanhamento de
Suprimentos” constando toda a programação para aquisição do software,
desde a sua solicitação até a entrega.
2.7.2 Documentos necessários
O Gerente de Projeto ou alguém da equipe com delegação para tal
solicitará formalmente a Gerência de Contratações a contratação de serviços e
para a Área responsável pelo controle de software, a aquisição e as licenças
dos mesmos.
Deverá ser aberto um pedido de contratação (PC), para contratação
da consultoria especializada, assim como a contratação do treinamento na
ferramenta de gestão de projetos.
Deverá ser gerada uma especificação contendo as necessidades e
o tipo de qualificação dos profissionais, tanto para o treinamento na ferramenta
de gestão, quanto para a contratação do consultor conforme dito no item de
critérios de qualificação. Esta especificação deverá ser anexada ao pedido de
contratação.
De posse destas informações a Gerência de Contratações,
preparará os editais de licitação ou as coletas de preços, encaminhando-as,
através de Carta-convite, aos prestadores de serviços / fornecedores
previamente qualificados. Esta qualificação tem pôr base informações
definidas pela equipe de projeto, além do cadastro de empresas existentes na
empresa.
Para a formalização e aquisição das licenças do software, deverá
ser encaminhado um e-mail à área de controle de licenças de software,
87
estabelecendo os prazos de utilização, número de licenças a serem adquiridas
e quem são os usuários que às utilizarão.
Critérios para avaliação e seleção das Propostas Apresentadas.
O Gerente de Projeto juntamente com a equipe de Implantação,
definirá o critério de julgamento para a escolha do Consultor e do treinamento
na ferramenta(Capacidade, disponibilidade, adequabilidade), além de seguir os
critérios de qualificação estabelecidos no processo de contratação.
De posse das propostas e com base nos critérios estabelecidos para
julgamento, a equipe de implantação após concluir as análises, deverá emitir
os Pareceres Técnicos, indicando as propostas tecnicamente aceitas e a
classificação das mesmas. A Gerência de Contratações analisará então as
propostas comerciais, indicando aquela que melhor atende às condições
técnico-econômicas para a contratação da Consultoria e do Treinamento,
verificando se existe margem para negociação dos valores e das condições.
A negociação, caso exista, ficará registrada no Contrato feito entre
as partes.
Esta etapa encerra-se com a Assinatura do Contrato ou com a
emissão da Ordem de Compra, no caso de aquisição de software.
88
CAPÍTULO 3
3. PROCESSO DE PLANEJAMENTO EXECUTIVO
3.1
Documentos e ferramentas
No processo de planejamento executivo serão apresentados os
documentos e ferramentas que serão utilizados para assegurar que o escopo,
qualidade, equipe, sistema de comunicação, solicitação de compras, escolha
de fornecedores e forma de distribuição de contratos estarão em conformidade
com todas as fases do projeto (MAXIMIANO, 1997).
3.1.1 Processo de aceitação formal
Para verificação do escopo, que consiste na aceitação formal pelos
envolvidos no projeto será utilizado o documento “ACEITAÇÃO FORMAL DE
PROJETO” e assegura que os trabalhos foram realizados de forma correta e
satisfatória.
Este documento deverá ser utilizado na finalização de cada fase do
projeto, garantindo assim a seqüência para a próxima fase.
89
3.1.2 Processo de ação corretiva das falhas
O processo de ação corretiva das falhas é um processo de melhoria
da qualidade, que inclui a tomada de ações para aumentar a efetividade e a
eficiência do projeto.
A implementação de melhorias na qualidade foram apontadas
detalhadamente nos requisitos de mudanças e tomadas de ações corretivas e
são gerenciadas de acordo com os procedimentos do controle geral de
mudanças.
Para o processo de ação corretiva das falhas será estabelecido um
documento de registro de problemas contendo as causas e as ações corretivas
a serem tomadas (LAUDON & LAUNDOM, 2004).
3.1.3 Processo para manutenção da equipe unida e coesa
Para o processo de desenvolvimento de equipe o item de melhoria
de performance é um bom indicador para manter a equipe unida e coesa.
Através da matriz de responsabilidades estarão sendo definidos os
papéis dos envolvidos no projeto e a necessidade de conhecimento técnico.
Cada um receberá um treinamento específico para execução de suas
atividades.
O nível de desempenho será feito através de avaliações mensais
baseadas nas atividades executadas na fase do projeto, conforme documento
de avaliação de desempenho utilizado na empresa.
3.1.4 Armazenamento de dados do Projeto
90
Os dados do projeto serão armazenados na rede local da empresa
por um período a ser definido pela equipe de Implantação do projeto.
3.1.5 Ferramentas do processo de contratação
Para obtenção de propostas de contratação, serão utilizadas
ferramentas e procedimentos já estabelecidos pela Gerencia de Contratação
da empresa.
O procedimento é:
A partir de cadastro de fornecedores potenciais existentes na
empresa e ou indicações do pedido de contratação, serão enviados os
requisitos técnicos e comerciais através de e-mail. As propostas serão
enviadas também através de e-mail.
Caso não haja entendimento dos requisitos técnicos e comerciais a
serem
contratados,
será
convocada
uma
reunião
de
licitação
para
compreensão clara e comum a todos os fornecedores.
3.1.6 Ferramentas utilizadas para definição das empresas a serem
contratadas e Cláusulas comuns dos contratos
Para definição das empresas a serem contratadas, será utilizada a
técnica de sistema de classificação baseado nos critérios de qualificações do
plano de contratações.
Cumpridos os requisitos técnicos, será utilizada a técnica de
negociação contratual para estabelecimentos dos requisitos comerciais
satisfatório.
Para elaboração do contrato serão utilizadas as cláusulas comuns
do padrão estabelecido no plano de contratação.
91
3.1.7 Processo para administrar os contratos
A administração de contratos é o processo que garantirá que a
performance dos contratados e fornecedores atinja o especificado nos
instrumentos de contratação (IMONIANA, 2008).
Para tal algumas ações serão necessárias:
•
gerente de projetos se incumbirá de divulgar as cláusulas contratuais mais
importantes aos membros da equipe e envolvidos,
de forma que não
cometam excessos ou uso inadequado ou insuficiente dos
serviços
previstos no contrato;
•
As relações contratuais com o consultor e com a empresa fornecedora de
licença de software se darão através de documentos formais para que se
registrem as ocorrências;
•
Ficará a cargo do gerente de projetos, ou de membro da equipe por ele
designado a execução das medições e encaminhamento das faturas ao
departamento financeiro, nos períodos definidos no contrato;
•
Será de responsabilidade do gerente de projetos aprovar e formalizar, com
o apoio do gerência e contratações, os aditivos de prazo e valor, caso se
faça necessário;
•
Será de responsabilidade do gerente de projetos a aplicação das sanções
legais previstas em contrato no caso de não cumprimento das cláusulas
nele previstas.
92
CAPÍTULO 4
4. PROCESSO DE CONTROLE GERAL DAS
MUDANÇAS
4.1
Controle de mudanças de escopo
4.1.1 Ferramentas
As ferramentas utilizadas no Controle das Mudanças de escopo são:
Declaração inicial de trabalho do Projeto (Scope Statement)
WBS do Projeto
Relatório de Performance do Projeto, com o Earned Value
Relatório de Custos do Projeto
Curva S do Projeto
Atividades Não programadas e Realizadas
Atividades Programadas e Realizadas
Atividades Programadas e Não Realizadas
4.1.2 Resultados esperados
Durante o processo de controle de qualidade, tempo, custo e riscos,
serão verificados se as atividades realizadas estão sendo conduzidas
conforme a previsão inicial (ISHIKAWA, 1993).
93
No caso da identificação de não conformidade de padrões de
qualidade definidos, de atrasos ou antecipações no cronograma, de custos
acima ou abaixo do previsto e da identificação de novos riscos ou do
acionamento de algum plano de contenção ou contingência de riscos, a equipe
deve observar se os motivos para tais problemas não são derivados de alguma
atividade ou custo não previsto inicialmente.
Em caso afirmativo, deve ser verificado se estes motivos
caracterizam uma mudança de escopo e então acionar o mecanismo
estabelecido para avaliação e autorização de mudança de escopo, definidos
no Plano de Comunicação.
Com isto, espera-se o pleno controle do andamento do projeto
dentro dos padrões especificados ou a pronta negociação das alterações no
menor prazo possível.
4.2
Controle das mudanças de tempo
A partir do cronograma definido para o projeto, será utilizado, além
do controle do caminho crítico, uma determinação probabilística do
cronograma do projeto.
Para tal será definida, para cada atividade, o tempo mínimo mais
provável e máximo de execução.
Utilizando-se a técnica PERT, o prazo será controlado com a
distribuição normal de probabilidade, considerando-se 1 desvio-padrão (o que
significa um prazo com 84% de segurança) e 2 desvio-padrão (o que significa
um prazo com 97% de segurança).
94
O prazo divulgado para os clientes será o com 97% de segurança (2
desvio-padrão). O prazo a ser controlado, e para o qual serão acionados os
dispositivos para redirecionamento do cronograma conforme o previsto, será o
com 84% de segurança (1 desvio-padrão).
As ferramentas utilizadas para redirecionamento do cronograma
serão:
Crashing
Redução do tempo das atividades pela utilização de recursos
adicionais, com aumento de custo;
Fast-tracking
Antecipação do início de atividades normalmente feitas em
seqüência por atividades em paralelo. Apesar do ganho em
tempo, geralmente resulta em trabalho e gastos adicionais;
Nivelamento de recursos, simulado com várias heurísticas (quando
o uso de um recurso é excedido num dado período de tempo, examinar as
tarefas ativas naquele instante e alocar o recurso escasso a elas de forma
seqüencial e usar regras de prioridades para ordenar as tarefas), como por
exemplo:
atividades
menor duração antes
rede
maior número de sucessores antes
caminho crítico
início mais cedo antes
uso de recursos
maior consumo de recursos antes
95
O MS-Project utiliza apenas a heurística de "menor duração de
atividade" e para o uso desta ferramenta, deve-se utilizar um outro software
além do MS-Project.
O acionamento destas ferramentas significa um acréscimo de custo
ao projeto. A reserva orçamentária necessária para tal está descrita no
Controle de mudanças de custo.
•
Distribuição Normal Reduzida
•
X
f(x)
F(x)
•
-3
0.004432
0.00135
•
-2.5
0.017528
0.00621
•
-2
0.053991
0.02275
•
-1.5
0.129518
0.066807
•
-1
0.241971
0.158655
•
-0.5
0.352065
0.308538
•
0
0.398942
0.5
•
0.5
0.352065
0.691462
•
1
0.241971
0.841345
•
1.5
0.129518
0.933193
•
2
0.053991
0.97725
•
2.5
0.017528
0.99379
•
3
0.004432
0.99865
X: desvio-padrão; f(x): probabilidade; F(x): probabilidade acumulada;
96
4.3
Controle de mudanças de custo
Para um melhor controle de custo, serão definidas três medições
para cada um dos itens de custo (software, consultoria, equipamentos, etc.)
como uma distribuição não-determinística, utilizando a distribuição triangular
(mínimo, mais provável e máximo).
Como os itens de custo são muitos, utilizaremos a técnica de
simulação de Monte Carlo com aplicação do Teorema do Limite Central.
Para esta simulação será utilizado o software @Risk, com a análise
do gráfico de tendência.
O valor a ser divulgado para os clientes será o com margem de
segurança correspondente a 80% da distribuição. O valor a ser controlado será
o com margem de segurança correspondente a 20% da distribuição.
Todos os custos serão trazidos a valor presente, utilizando-se
também uma distribuição triangular de probabilidade para as taxas de juros.
A verificação da execução do projeto será feita através da análise do
gráfico de tendência do Earned Value.
97
4.4
Processo e ferramentas de controle de qualidade
4.4.1 Controle de Documentos e Dados
Deverá ser estabelecido e mantido procedimento documentado para
controle de todos os documentos e dados relacionados aos requisitos do
projeto.
O objetivo desse procedimento é de assegurar que:
Todos os documentos e dados analisados criticamente e aprovados, por
pessoal autorizado, antes de sua emissão, assim como as alterações a eles
pertinentes;
Os documentos emitidos estarão disponíveis em todos os locais onde são
executadas operações essenciais para o funcionamento eficaz do Sistema
da Qualidade;
Documentos não válidos e/ou obsoletos serão removidos evitando assim
seu uso não intencional;
Quaisquer documentos obsoletos retidos por motivos legais e/ou para
preservação do conhecimento deverão ser adequadamente identificados;
As cópias controladas do Sistema da Qualidade serão relacionadas nas
Listas–mestras, indicando a versão atual, data de emissão, responsável
pela emissão/alteração, responsável pela aprovação e distribuição;
As cópias não controladas do Sistema da Qualidade poderão ser
distribuídas para informação de clientes e fornecedores, não sendo
necessária sua atualização;
Manual da Qualidade referencia somente os PRO’s. Por extensão inclui-se
todo o desdobramento da documentação.
98
4.4.2 Controle de Hardware e Software adquiridos
Deverão
ser
estabelecidos
e
mantidos
procedimentos
documentados para o controle e verificação, armazenamento e manutenção de
hardware e softwares adquiridos ao longo do projeto, destinado às atividades
relacionadas a prestação dos serviços especificados no Definição do Escopo.
Com o objetivo de manter a integridade dos produtos fornecidos
pelo cliente e a qualidade dos serviços prestados será relatado ao cliente
qualquer inadequação de uso, dano ou extravio ocorrido com esses produtos.
As
comunicações
de
irregularidades
serão
informadas
imediatamente após a ocorrência do fato via correio eletrônico e registrado no
Relatório de Avaliação Mensal do projeto.
4.4.3 Identificação e Rastreabilidade do Produto
A identificação dos produtos gerados pelo projeto obedecerá ao
Procedimento Operacional – Identificação e Rastreabilidade do Produto com o
objetivo de garantir a perfeita rastreabilidade dos produtos individualmente ou
em lotes desde sua entrada e durante o desenvolvimento, homologação e
divulgação de cada fase da metodologia.
Estarão sujeitos a esse Procedimento todos os produtos resultantes
dos processos relacionados no Escopo do Projeto.
99
4.4.4 Controle de Produto Não-Conforme
Serão estabelecidos e mantidos procedimentos documentados para
analisar e dispor sobre produtos/serviços que não estejam em conformidade
com os requisitos especificados no Sistema da Qualidade Área de TI.
O controle de produtos/serviços não-conformes será executado
com o objetivo de impedir que produtos e serviços que não atendam aos
requisitos especificados sejam utilizados (PRADO, 2003).
4.4.5 Ações Corretivas e Preventivas
Serão registradas as ações preventivas e corretivas efetuadas
durante o projeto com vistas a eliminar as causas de não-conformidades reais
e/ou potenciais e implementar ações efetivas.
As ações corretivas e preventivas serão analisadas utilizando-se as
ferramentas da qualidade com destaque para o Diagrama de Causas e Efeitos
(também chamado Ishikawa) e o Diagrama de Pareto.
4.4.6 Auditorias Internas da Qualidade
As auditorias da qualidade são efetuadas para determinar a
adequação do programa de qualidade (documentação) em relação às normas
estabelecidas e à conformidade das operações dentro do sistema da qualidade
à documentação do programa da qualidade.
Assim sendo, a gestão destas atividades será desenvolvida nos
termos do ciclo tradicional de gerenciamento (PDCA).
100
O sistema de qualidade envolve todas as quatro fases do
gerenciamento, enquanto o programa da qualidade envolve apenas a fase de
planejamento.
Independente das possíveis auditorias que poderão ser realizadas
pela Auditoria Interna da empresa, o projeto deverá ser auditado por uma
empresa externa que já faça este tipo de serviço para a empresa ao final da
fase de customização da metodologia.
4.4.7 Treinamento para a Qualidade
Todos os membros da equipe deverão desenvolver habilidades
necessárias para a execução das tarefas que influem na qualidade dos
produtos do projeto (AGUSTIN & MARTIUS, 2004).
O Gerente do Projeto é responsável pelo levantamento das
necessidades de treinamento em Qualidade, execução do plano de
treinamento e avaliação de sua eficácia.
Na
Matriz
de
Treinamento
deverão
constar
dos
seguintes
treinamentos básicos:
Sistema de Qualidade Área de TI
Gestão da Qualidade Total
Normas ISO 9000 e 10000
Ferramentas Estatísticas da Qualidade
5S
Auditoria de Qualidade
4.4.8 Principais Ferramentas Estatísticas da Qualidade
Para o gerenciamento da qualidade nos projetos da Área de TI
deverão ser utilizadas as ferramentas já consagradas da qualidade, a saber:
Estratificação
Folha de Verificação
101
Gráfico de Pareto
Diagrama de Causa e Efeito
Diagrama de Correlação
Histograma
Carta de Controle
4.4.9 Principais Normas, Padrões e Regulamentos
Dada as características dos projetos a serem implantados na área
de TI deverão ser elaborados e seguidos os seguintes padrões que garantirão
a qualidade nos projetos:
Procedimentos para Implantação de Projetos;
Norma para determinação de Unidades de Projeto;
Norma para numeração de documentos;
Norma para identificação de equipamentos;
Norma para planejamento;
Norma para Gerenciamento de Projeto de Sistemas;
Norma para Gerenciamento de Projetos de Consultoria;
Norma para Gerenciamento de Projetos de Infra-estrutura;
Especificações Técnicas de Serviços;
Normas de Segurança Física e Lógica.
4.4.10 Ferramentas e relatórios de performance do projeto
Após a identificação dos itens do projeto a serem monitorados e o
efetivo início da coleta de dados, serão utilizadas as seguintes ferramentas
para avaliar a performance do projeto:
Inspeção
Gráficos de controle
102
Amostragem estatística
Carta de controle
Histograma
Diagrama de correlação
Análise de tendência
Fluxograma de decisão
Diagrama de causa e efeito
Inspeções
Walkthroug´s
Processo cleanroom
Com isto, o bom andamento do projeto será garantido através de
ações preventivas e corretivas, realinhando-se o projeto para atender aos
resultados
esperados ou iniciando um processo de mudança de escopo,
quando necessário e justificável.
4.4.11 Ferramentas e processos para controle de riscos
O controle de resposta aos riscos já identificados e quantificados
será realizado através das Fichas de Controle de Risco II e III.
Novos riscos identificados por qualquer nível da equipe envolvida no
projeto será quantificado através da Ficha de Controle de Risco I.
Além do controle dos riscos ser uma tarefa realizada diariamente por
todos os participantes do projeto, conforme definido no Gerenciamento dos
Riscos, ao final de cada etapa do WBS serão revistos todos os relatórios de
andamento do projeto, num brainstorm visando a identificação de novos riscos.
Será utilizado o plano de contenção correspondente ao risco e,
excepcionalmente, o plano de contingência.
103
O gatilho para acionamento do Plano de Gerenciamento de Risco
será a análise do gráfico de tendência do Earned Value.
104
CAPÍTULO 5
5. PROCESSO DE ENCERRAMENTO DO PROJETO
5.1
Encerramento administrativo
O encerramento administrativo consiste em verificar e documentar
os resultados do projeto e formalizar a aceitação do produto do projeto pelos
patrocinadores, clientes, etc. Isto inclui a coleta dos registros do projeto para
garantir que eles reflitam as especificações finais, a análise do sucesso e da
efetividade do projeto e o arquivamento dessas informações para uso futuro
(REZENDE, 2005).
As atividades do encerramento administrativo não devem ser
retardadas até a conclusão do projeto. Cada fase do projeto dever ser
apropriadamente encerrada para assegurar que as informações úteis e
importantes não sejam perdidas.
O marco final é a obtenção da aceitação formal do projeto pelo
patrocinador e pelo cliente.
5.1.1 Encerramento do Contrato
O Gerente do Projeto deve reunir toda a documentação do contrato
incluindo o próprio contrato junto com todos os cronogramas de suporte,
mudanças contratuais requisitadas e aprovadas, toda documentação técnica
desenvolvida pelo fornecedor, relatórios de desempenho do fornecedor,
105
documentos financeiros tais como faturas e registros de pagamentos, e os
resultados de quaisquer inspeções relacionadas ao contrato.
Conferidos todos os documentos e recebido o aceite do cliente, o
Gerente do Projeto deve informar o término do contrato ao fornecedor, através
de notificação formal escrita (Termo de Entrega e Recebimento). Os
requerimentos para aceitação formal e fechamento estão definidos no contrato.
O Gerente de Projeto e a equipe de contratação realizarão uma
revisão estruturada do processo de contratação desde o planejamento da
contratação até a administração do contrato. O objetivo dessa auditoria é
identificar os sucessos e falhas que possam ser transferidos para outros
projetos da organização executora.
O Gerente do Projeto, como gestor do contrato, deverá obter junto a
contratada a documentação que julgar necessária à comprovação do
cumprimento de encargos fiscais, trabalhistas e previdenciários aos serviços,
em especial a Certidão Negativa de Débito (CND) do INSS e o Certificado de
Regularidade de Situação com o FGTS. Cópia dos comprovantes devem ser
anexadas às medições e Notas Fiscais
quando do encaminhamento da
liberação de pagamentos das atividades encerradas.
O Gerente de Projeto no encerramento final deverá emitir:
1) Ao término das atividades do contrato o Termo de Entrega e Recebimento;
2) Quando do encerramento de todas as obrigações contratuais o Termo de
Encerramento Contratual;
3) Análise de Desempenho do Contratado.
O Termo de Encerramento Contratual é assinado pelo representante
do contratado, pelo gerente do contrato e pelo autorizador do contrato.
106
5.2
Acervo do Projeto
Encerradas as atividades do projeto o Gerente do Projeto deverá
proceder à montagem do acervo.
O Acervo do Projeto é um conjunto completo de todos os registros
do projeto indexados e preparados para arquivamento.
Os
registros
do
projeto
constam
basicamente
documentação:
Planejamento do projeto;
Especificações técnicas de aquisição e contratação;
Especificações técnicas de construção de software;
Documentação técnica entregue pelos fornecedores;
Plantas baixas, unifiliares, etc.;
Arquivos eletrônicos de correio eletrônico e fax;
Medições dos contratos;
Correspondências;
Memorandos;
Relatórios;
Manuais de usuário do sistema;
Fontes;
Procedimentos operacionais do sistema;
Manuais técnicos do sistema.
da seguinte
107
5.3
Aceite Final do projeto
O Gerente do Projeto apresentará o Relatório de Acompanhamento
Final do Projeto procurando obter o aceite formal do cliente ou patrocinador à
entrega do produto do projeto.
Devem ser destacados o atendimento ao escopo original e a
revisado do projeto, e uma análise comparativa com relação a custo, prazo e
qualidade do produto entregue.
A documentação de que o cliente ou patrocinador aceitou o produto
do projeto será preparada e distribuída aos stakeholders. A aceitação pode ser
condicional e não se dará o aceite final do projeto até que todos os itens
rejeitados tenham sido corrigidos (KERZNER, 2005).
O cliente e o patrocinador preencherão um formulário em que serão
analisados a qualidade do serviço e o nível de satisfação dos mesmos com
relação ao produto entregue.
5.4
Lições Aprendidas
Ao término de cada fase e ao término do projeto, o Gerente do
Projeto deve reunir todos os participantes para avaliarem o produto entregue,
as causas das variâncias, as razões por trás das ações corretivas tomadas, e
outros tipos de aprendizado prático (CAVALIERI, 2006).
As lições aprendidas devem ser documentadas integrando um
banco de dados histórico não só para o projeto em andamento, mas para os
demais projetos da Área de TI.
108
CONCLUSÃO
No presente trabalho foi proposta a implantação da metodologia do
PMI – Project Management Institute, por ser a mesma um instrumento
fundamental para o processo de Planejamento Integrado de Tecnologia da
Informação e de garantia de atendimento dos requisitos de escopo, prazo,
custo e qualidade esperados pelos clientes/usuários da área de Tecnologia da
Informação das empresas.
A execução de projetos de Informática apresenta singularidades em
relação à maioria dos projetos de construção, montagem, pesquisa, etc. quer
pela sua complexidade, pela dificuldade de visualizar claramente o produto
que em desenvolvimento ou mesmo pelas dificuldades de comunicação entre
executor e usuário ou cliente.
Atualmente, a Informática vive um cenário de múltiplos projetos com
grandes dependências interdepartamentais, onde o tempo em que as
mudanças ocorrem é cada vez menor e aumenta a insatisfação das empresas
com a pouca habilidade das suas áreas de informática em desenvolverem
produtos estratégicos a custos, prazos e qualidade demandados pelo mercado.
Para suportar tal pressão, é preciso que a comunidade de
informática mude. Que se conscientize da importância em utilizar técnicas
gerenciais em seu dia a dia, de que projetos diferentes são gerenciados de
maneira diferente e exigem interações diferenciadas com o cliente/usuário.
Para mudar esse cenário, é preciso formalizar técnicas, ferramentas
e métodos que assegurem tanto o gerenciamento eficaz dos projetos de
sistemas de informação e tecnologia para seus clientes, quanto aqueles de
109
desenvolvimento interno de metodologias, padrões, diretrizes e pesquisa de
novas tecnologias.
Como resultado da implantação da metodologia, espera-se obter a
definição de rotinas, ferramentas de trabalho, atribuições, responsabilidades e
formação de expertise em gerência de projetos e o planejamento da
implementação do modelo de gestão PMI na empresa, abordando os seguintes
itens:
Adequação da Metodologia de Desenvolvimento de Sistemas;
Definição de Metodologia para Projetos de Infra-estrutura;
Definição de Metodologia para Desenvolvimento de Diretrizes e Padrões
Tecnológicos;
Definição de Metodologia para Pesquisas Tecnológicas;
Definição de Metodologia para Projetos de Gerenciamento de Tecnologia
da Informação;
Adequação da Metodologia de Desenvolvimento de projetos de Tecnologia;
Análise de viabilidade de implantação de um Project Office;
Efetivar treinamentos na metodologia e nas ferramentas para apoio ao
planejamento e programação de projetos, não só para gerentes, mas para
todos os membros da equipe;
Criação de Templates (Análise de Custo Benefício, cronogramas, análise
de desempenho, aceite formal) comuns de forma a se obter um padrão de
documentação em todos os projetos efetivados pela empresa;
Escolha e execução de um projeto piloto para demonstração dos resultados
do uso da gerência de projetos;
Formação de competência interna em gestão de projetos, fazendo com que
os profissionais se certifiquem e tornem-se membros do PMI, assim como
a empresa.
O projeto foi dividido em 6 fases.
110
Na
fase
de
iniciação
foram
elaboradas
as
atividades
de
comprometimento de toda a empresa e de obtenção do apoio explicito da
gerência para a implantação da Gestão de Projetos.
Na fase seguinte, foi realizado o planejamento global do projeto
contendo a programação de todas as atividades, cronograma, recursos,
custos, orçamento, plano de qualidade, plano de comunicação, plano de
gerenciamento de riscos e plano de contratação.
As fases executivas ocorrem, normalmente, em paralelo e constam
dos seguintes processos: aquisições e contratações – especificação, coleta de
preços, julgamento, compra e contratação de todos os materiais e serviços
necessários à execução do projeto; Customização das metodologias da
empresa acrescentando os processos de gestão de projetos do PMI. As
ferramentas e processos que foram definidos serão experimentados para
garantir se estão adequados ou não ao ambiente da empresa.
E, finalmente, uma fase de revisão de todos os procedimentos,
encerramento dos contratos, análise da lição aprendida e criação de todo
acervo técnico e encerramento de todos os contratos.
Essa metodologia foi implantada numa grande empresa de
mineração e logística e numa outra de turismo. Em ambas as situações, não
houve impacto nos projetos em andamento e houve uma mudança na cultura
dessas duas empresas com relação às práticas de gerência de projetos e
negociação de prazos e custos com os clientes, o que melhorou o nível de
satisfação dos usuários e clientes com a área de Tecnologia da Informação.
A criação de um roteiro detalhado para implantação do PMI em
empresas brasileiras de grande porte garantiu nessas duas empresas onde foi
implantado uma gestão efetiva dos projetos de TI e uma melhora na visão dos
profissionais que atuam nessa área, atingindo de forma plena os resultados
esperados.
111
A metodologia poderá ser implantada em outras empresas que
estejam dispostas a investir o capital financeiro e humano necessários e colher
os resultados previstos, os quais superam todo o investimento realizado.
112
BIBLIOGRAFIA
AGUSTIN, J.F. MARTIUS, V.R.R.. Tecnologia de Informação e Gestão
Empresarial. São Paulo – Editora e-papers,2004.
ALENCAR, A.J. Disciplina Análise de Risco na Gerência de Projetos de
Tecnologia da Informação, Universidade Ferderal do Rio de Janeiro, NCE,
2008.
BROOKS, F.P. No silver bullet: essence and accidents of software
engineering. North Holland – Elsevier Science, 1986.
CAVALIERI, A. Gerenciamento de Projetos: Como se Tornar um
Profissional em Gerenciamento de Projetos. São Paulo – Qualitymark,
2006.
DAYCHOUM, M. 40 ferramentas e técnicas de gerenciamento.Rio de
Janeiro – Brasport. 2007.
GARTNER GROUP. Insight. 2010.
Disponível em <http://www.gartner.com/technology/home.jsp>
Acessado em: 15/09/2010 Hora: 09:47:00
IMONIANA, J.O. Auditoria de Sistemas de Informação. São Paulo – Atlas,
2008.
ISHIKAWA, K. Controle de Qualidade Total à maneira japonesa. Rio de
Janeiro. Editora Campus, 1993.
113
JONES, C. Software Engineering Best Practices: Lessons from
Successful Projects in the Top Companies. USA – McGraw-Hill, 2010.
KAROLAK, D.W. Software Engeneering Risk Management. USA – IEEE
Computer Society Press, 2006;
KERZNER, H. Gestão de projetos: As Melhores Práticas. São Paulo –
Bookman, 2005.
LAUDON, K.C. LAUDON, J.P. Sistemas de Informações Gerenciais, São
Paulo – Editora Pearson, 2004.
MAXIMIANO, A.C. Administração de projetos: transformando idéias em
resultados. São Paulo – Atlas, 1997.
PMI – Project Management Institute. PMBOK – Project management body of
knowledge guide. PMI,2004.
PMI ORANGE COUNTY CHAPTER. Resources. 2010.
Disponível: <http://www.pmi-oc.org/>
Acessado em: 10/09/2010 Hora: 18:32:00
PRADO, D. Gerenciamento de Projetos nas Organizações. São Paulo –
EDG, 2003.
REZENDE, D.A. Engenharia de Software e Sistemas de Informação. São
Paulo – Editora Brasport, 2005.
STANDISH GROUP INTERNATIONAL. Relatório Annual. 2010.
Diponível em <http://www.standishgroup.com/>
Acessado em: 05/09/2010 Hora: 15:20:00
114
THAMHAIN, H. J. WILEMON, D. L. Conflict Management in ProjectOriented Work Environments. Washington, D.C. – Proceedings of the Sixth
International Meeting of the Project Management Institute, 1974.
VARGAS, R.V.. Gerenciamento de projetos: estabelecendo diferenciais
competitivos. São Paulo – Brasport, 2006
WANG, C.B. O Novo Papel do Executivo de Informática. São Paulo –
Makron Books, 1995.
YOURDON, E. Projetos Virtualmente Impossíveis. São Paulo – Makron
Books, 2004.
115
ÍNDICE
AGRADECIMENTOS
03
DEDICATÓRIA
04
RESUMO
05
METODOLOGIA
06
SUMÁRIO
07
INTRODUÇÃO
08
CAPÍTULO 1
11
O PROCESSO INICIAL
1.1 Project Charter
11
1.1.1 Histórico
11
1.1.2 Objetivo
15
1.1.3 Descrição do Produto
16
1.2 Gerente de Projeto
16
1.3 Restrições
17
1.3.1 Orçamento
1.4 Premissas
17
17
1.4.1 Fatores Críticos de Sucesso
18
1.4.2 Benefícios
18
116
CAPÍTULO 2
20
PLANEJAMENTO GERAL DO PROJETO
2.1 Planejamento do Escopo
20
2.1.1 Justificativa do Projeto
20
2.1.2 Plano do Gerenciamento do Escopo
25
2.2 Definição do Escopo
2.2.1 Estrutura Analítica do Projeto (WBS)
2.3 Planejamento de Qualidade
26
27
27
2.3.1 Política de Qualidade da Empresa
27
2.3.2 Política de Qualidade da Área de Tecnologia da Informação
28
2.3.3 Missão da Área de Tecnologia da Informação
29
2.3.4 Crenças e Valores
29
2.3.5 A Implantação da Gestão de Projetos e a Qualidade
30
2.3.6 Sistema de Qualidade
30
2.4 Planejamento Organizacional
35
2.4.1 Matriz de Responsabilidades
38
2.4.2 OBS – Organization Breakdown Structure
39
2.5 Plano de Comunicações
40
2.5.1 Introdução
40
2.5.2 Objetivos do Planejamento da Comunicação
40
2.5.3 Política de Comunicação
41
2.5.4 Fluxo de Comunicação
42
2.5.5 Habilidades do Gerente de Projeto
42
2.5.6 Distribuição das Informações
43
2.5.7 Relatório de Performance
45
2.5.8 Documentos de Comunicação
45
117
2.5.9 Controle de Comunicação
50
2.6 Plano de Gerenciamento de Riscos
52
2.6.1 Identificação dos Riscos do projeto
55
2.6.2 Quantificação dos riscos
62
2.6.3Plano de Gerenciamento dos Riscos
79
2.7 Plano de Contratações
84
2.7.1 Tipos de contratos que serão firmados
84
2.7.2 Documentos Necessários
86
CAPÍTULO 3
88
PROCESSO DE PLANEJAMENTO EXECUTIVO
3.1 Documentos e ferramentas
88
3.1.1 Processo de aceitação formal
88
3.1.2 Processo de ação correitva de falhas
89
3.1.3 Processo para manutenção da equipe unida e coesa
89
3.1.4 Armazenamento de dados do Projeto
89
3.1.5 Ferramentas do processo de contratação
90
3.1.6 Ferramentas utilizadas para definição das empresas a serem
contratadas e Cláusulas comuns dos contratos
3.1.7 Processo para administrar os contratos
CAPÍTULO 4
90
91
92
PROCESSO DE CONTROLE GERAL DAS MUDANÇAS
4.1 Controle de mudanças de escopo
92
4.1.1 Ferramentas
92
4.1.2 Resultados Esperados
92
118
4.2 Controle das mudanças de tempo
93
4.3 Controle de mudanças de custo
96
4.4 Processo e ferramentas de controle de qualidade
97
4.4.1 Controle de Documentos e Dados
97
4.4.2 Controle de Hardware e Software adquiridos
98
4.4.3 Identificação e Rastreabilidade do Produto
98
4.4.4 Controle de Produto Não-conforme
99
4.4.5 Ações Corretivas e Preventivas
99
4.4.6 Auditorias Internas da Qualidade
99
4.4.7 Treinamento para Qualidade
100
4.4.8 Principais Ferramentas Estatísticas da Qualidade
100
4.4.9 Principais Normas, Padrões e Regulamentos
101
4.4.10 Ferramentas e relatórios de performance do projeto
101
4.4.11 Ferramentas e processos para controle de riscos
102
CAPÍTULO 5
104
PROCESSO DE ENCERRAMENTO DO PROJETO
5.1 Encerramento administrativo
5.1.1 Encerramento do Contrato
104
104
5.2 Acervo do Projeto
106
5.3 Aceite Final do Projeto
107
5.4 Lições Aprendidas
107
CONCLUSÃO
108
BIBLIOGRAFIA
112
ÍNDICE
115