Plano Do Projeto Backoofice Modelo

MIT030 – PLANO DO
PROJETO
Nome do projeto: Implantação ERP Totvs – Módulos BackOffice
Plano do Projeto
Data: 23/04/2015
Responsáveis: Michihiko Tanimoto
Aprovadores: Ronaldo Vitória
Adilson de Oliveira
Revisão: 1.0
MIT030 – Plano do Projeto

44
MIT030 – PLANO DO
PROJETO
Índice
1. INTRODUÇÃO.............................................................................................6
ESTRATÉGIA........................................................................................................................ 6
2. RESUMO DO PROJETO.................................................................................7
2.1. NOME DO PROJETO:....................................................................................................... 7
2.2. PATROCINADOR (SPONSOR):...........................................................................................7
2.3. GERENTE DO PROJETO DO CLIENTE, AUTORIDADE E RESPONSABILIDADE ATRIBUÍDA:....................7
2.4. FATORES DE SUCESSO DO PROJETO:..................................................................................7
2.5. MACRO ESCOPO:.......................................................................................................... 8
2.6. RESTRIÇÕES:............................................................................................................... 8
2.7. PREMISSAS:............................................................................................................... 10
2.8. LIMITES DO PROJETO (EXCLUSÕES):.................................................................................11
2.9. CONTROLE E GERENCIAMENTO DAS INFORMAÇÕES DO PROJETO:...........................................11
2.10. REGISTRO DAS ALTERAÇÕES DO PLANO DO PROJETO:.......................................................12
3. GERENCIAMENTO DO ESCOPO...................................................................12
3.1. DECLARAÇÃO DO ESCOPO............................................................................................. 12
3.2. DICIONÁRIO DA EAP.................................................................................................... 14
3.3. PLANO DE CARGA....................................................................................................... 17
3.4. PLANO DE TESTES....................................................................................................... 18
3.5. PLANO DE INTEGRAÇÃO................................................................................................ 20
3.6. PROCESSO PARA VERIFICAR O ESCOPO AO FINAL DAS ENTREGAS PARA ACEITE DO CLIENTE:.........21
3.7. REGRAS PARA SOLICITAR MUDANÇAS DE ESCOPO:..............................................................21
3.8. PROCESSO PARA PRIORIZAR SOLICITAÇÕES DE MUDANÇAS DE ESCOPO:...................................22
4. GERENCIAMENTO DO CRONOGRAMA..........................................................24
4.1. CRONOGRAMAS DETALHADOS COM BASE NA LISTA DE ATIVIDADES.........................................24
4.2. REGRAS PARA SOLICITAÇÃO DE MUDANÇAS, AÇÕES CORRETIVAS OU PREVENTIVAS A PARTIR DA
ANÁLISE DE VARIAÇÃO DO CRONOGRAMA:...............................................................................24
4.3. RESERVA DE HORAS PARA RISCOS DE CRONOGRAMA (ATIVIDADES BUFFERS):...........................25
5. GERENCIAMENTO DA QUALIDADE..............................................................25
5.1. MÉTRICAS E METAS DE QUALIDADE:................................................................................25
5.2. LISTAS DE VERIFICAÇÃO DA QUALIDADE:..........................................................................25
5.3. MUDANÇAS, AÇÕES CORRETIVAS E AÇÕES PREVENTIVAS NOS PADRÕES DE QUALIDADE
ESTABELECIDOS E APROVADOS:............................................................................................. 29
6.4. REGRAS PARA MEDIÇÕES DE CONTROLE DA QUALIDADE DAS ENTREGAS:.................................30
5.5. PROCESSO PARA REGISTRAR ERROS E PROBLEMAS:............................................................30
6. GERENCIAMENTO DO PESSOAL..................................................................31
6.1. MATRIZ DE ATRIBUIÇÃO DE RESPONSABILIDADES:...............................................................31
6.2. FUNÇÕES, AUTORIDADE, RESPONSABILIDADE E COMPETÊNCIAS NECESSÁRIAS PARA OS MEMBROS DO
PROJETO:.......................................................................................................................... 31
6.3. ORGANOGRAMA DO PROJETO:........................................................................................33
6.4. NECESSIDADE DE TREINAMENTO IDENTIFICADA:.................................................................33
7. GERENCIAMENTO DAS COMUNICAÇÕES......................................................34
7.1. PLANEJAMENTO DAS COMUNICAÇÕES:..............................................................................34
7.2. REGRAS E CRITÉRIOS PARA DISTRIBUIÇÃO DAS INFORMAÇÕES:..............................................34
7.3. FORMATO E REGRAS PARA COMUNICAR DESEMPENHO DO PROJETO:........................................34

44
MIT030 – PLANO DO
PROJETO
7.4. PROCESSO PARA GERENCIAR AS COMUNICAÇÕES COM AS PARTES INTERESSADAS:.....................38
8. GERENCIAMENTO DOS RISCOS...................................................................38

8.1. PROCESSO PARA IDENTIFICAR OS RISCOS:.........................................................................39
8.2. PROCESSO PARA QUALIFICAR E PRIORIZAR OS RISCOS IDENTIFICADOS:....................................40
8.3. PROCESSO PARA QUANTIFICAR O IMPACTO DOS RISCOS NOS OBJETIVOS DO PROJETO:................40
8.4. RESERVAS PARA OS RISCOS IDENTIFICADOS:......................................................................41
8.5. RESERVAS PARA RISCOS NÃO IDENTIFICADOS:....................................................................42
8.6. REGRAS PARA UTILIZAÇÃO DAS RESERVAS:........................................................................42
8.7. PROCESSO PARA PLANEJAR RESPOSTAS AOS RISCOS IDENTIFICADOS:......................................42
8.8. PROCESSO PARA MONITORAR E CONTROLAR OS EVENTOS DE RISCOS:....................................42
8.9. PROCESSO PARA REGISTRO DOS RISCOS:..........................................................................43
8.10. REGRAS PARA SOLICITAR MUDANÇAS NO PROJETO EM FUNÇÃO DA IDENTIFICAÇÃO DE NOVOS
RISCOS:........................................................................................................................... 44
8.11. REGRAS PARA ATUALIZAR ESTE PLANO A PARTIR DE MUDANÇAS NOS RISCOS:.........................44
8.12. REGRAS PARA QUESTÕES DE RISCOS NÃO PREVISTAS NESTE PLANO:.....................................45
9. GERENCIAMENTO DA INTEGRAÇÃO............................................................45
9.1. PROCESSO E REGRAS PARA EXECUÇÃO DE ATIVIDADES DO PROJETO.......................................45
9.2. PROCESSO E REGRAS PARA MONITORAMENTO E CONTROLE DO TRABALHO DO PROJETO:.............45
9.3. PROCESSO E REGRAS PARA CONTROLE, INTEGRAÇÃO E APROVAÇÃO DAS MUDANÇAS SOLICITADAS:
...................................................................................................................................... 46
9.4. PROCESSO E REGRAS PARA ENCERRAMENTO DO PROJETO:....................................................47

44
MIT030 – PLANO DO
PROJETO
1. Introdução
O propósito desse documento é estabelecer o entendimento comum entre os
patrocinadores e a equipe do projeto, em termos de expectativas e objetivos do projeto.
O Plano de projeto estabelece os fundamentos e estratégias do mesmo, documentando:
 Objetivos;
 Escopo;
 Riscos;
 Premissas;
 Fatores de sucesso;
 Planejamento.
O plano de projeto é a declaração de entendimento dos objetivos do projeto e

comprometimento de todos os envolvidos. Sendo assim, seu entendimento é
extremamente importante. Também é a base para avaliar qualquer alteração de escopo e
objetivos do projeto, além de análise do impacto das alterações propostas nos prazos e
custos. O plano de projeto é a base para o processo de execução da equipe de projeto, e
também servirá como base para avaliar o desempenho, direção e resultados do projeto
pelos “stakeholders” do mesmo.
Estratégia
A estratégia adotada para a implantação e gerenciamento do projeto envolve:
 O entendimento e alinhamento de expectativas entre a TOTVS (Mit Tecnologia) e a

Universidade de Mogi das Cruzes em termos de prazos e abrangência do projeto e,
ainda, clara definição dos produtos finais a serem entregues e responsabilidades
envolvidas;
 A aplicação da metodologia de gerenciamento do projeto acordada neste documento

é baseada na MIT (Metodologia de Implementação TOTVS);
 Nomear o Gestor do Projeto, o qual terá a função de planejar, monitorar, medir e

acompanhar toda a evolução do projeto, até a entrega oficial do mesmo. Este Gestor
do Projeto controlará a qualidade e produtividade da equipe envolvida, fazendo
ajustes se necessário.
 Serão alocados consultores especialistas nos módulos e serviços comprados,

garantindo assim o entendimento das áreas usuárias bem como a correta
configuração e entrega do produto.
 Monitoramento dos serviços desenvolvidos para garantir a integral aderência às

expectativas da Universidade de Mogi das Cruzes, conforme descrito explicitamente
no escopo do projeto deste documento.
 Nenhuma alteração de escopo será aceita sem passar por um processo de mudança
formal.

44
MIT030 – PLANO DO
PROJETO
 Entende-se como alteração de escopo qualquer item não explicitamente descrito e
aqueles explicitamente descritos no item “Itens fora de escopo” deste documento.
Alterações neste documento serão efetuadas de maneira controlada, bem como
comunicadas com o resultado de decisões em consenso. As decisões de mudanças
somente terão efeito sobre o projeto após o aceite dos envolvidos e suas devidas
assinaturas neste documento.
 Essas mudanças serão divulgadas formalmente para os membros do projeto, para

assegurar que os mesmos serão informados pela alta gestão do projeto.
 Somente o comitê diretivo tem a responsabilidade e autoridade de promover e decidir

as mudanças solicitadas.
2. Resumo do Projeto
2.1. Nome do projeto:

ERP Totvs – Módulos BackOffice
2.2. Patrocinador (Sponsor):

Ronaldo Vitória
2.3. Gerente do projeto do cliente, autoridade e responsabilidade

atribuída:
Adilson de Oliveira
2.4. Fatores de sucesso do projeto:

 Ter escopo claro e definido;
 Prazo compatível com o escopo;
 Equipe de TI envolvida full time;
 Treinamento prévio dos usuários e evitar a substituição dos mesmos ao longo do

projeto;
 Disponibilidade dos usuários para executarem as atividades de implementação;
 Não ocorrer interrupções na execução do projeto, respeitando o planejamento;
 Tarefas concluídas pelos usuários conforme planejado;
 Promover reuniões periódicas com o comitê;
 Garantir que o projeto não concorrerá por recursos com outros projetos em
andamento;
 Definição de um processo de comunicação claro e objetivo;
 Envolvimento do patrocinador, promovendo a mudança de cultura na empresa;
 Disponibilizar a infraestrutura necessária ao projeto (sala, máquinas, rede, telefone,

etc.);

44
MIT030 – PLANO DO
PROJETO
 Definir uma política de migração ou digitação de dados clara, além de garantir seus
resultados;
Audi
Melhores Práticas de Gerenciamento de Projetos
Metodologi
2.5. Macro Escopo:
Segue o EAP em Anexo I para melhor visualização.
2.6. Restrições:
Não fazem parte do escopo desta proposta os itens abaixo relacionados:
Desenvolvimento e Customizações:
 Especificação de sistemas e/ou funcionalidades que não façam parte da

implementação dos produtos TOTVS;

44
MIT030 – PLANO DO
PROJETO
 Desenvolvimento de programas ou produtos específicos complementares ao produto
padrão, exceto os já previstos na Proposta Comercial ou nos formulários de
“Especificação de Personalização” já aprovados;
 Desenvolvimento de programas específicos de interface entre os produtos TOTVS com

outros softwares, existentes ou a serem adquiridos que não estejam descritos no
escopo do projeto, nas instalações da Universidade de Mogi das Cruzes;
 Desenvolvimento de programas específicos para a importação da carga de dados,

exceto os previstos “em contrato”, efetuados os respectivos orçamentos;
 Execução e desenvolvimento de programas para extração de dados das bases de

dados dos sistemas legados da Universidade de Mogi das Cruzes;
Infraestrutura Tecnológica:
 Fornecimento de softwares ou hardwares básicos ao desenvolvimento do projeto

(ferramentas de programação, sistema operacional, editor de texto, planilhas
eletrônicas e relatórios exigidos pela Universidade de Mogi das Cruzes não previstos
no sistema);
 Fornecimento de softwares de segurança ou para sistemas operacionais;
 Configuração de rede ou instalação de softwares básicos;
 Configuração de links de acesso remoto entre pontos distintos;
 Serviços de administração de banco de dados;
 Rotinas de backup de servidores ou bancos de dados;
Implementação:
 Treinamento para usuários finais e de implementação de quaisquer módulos e

processos que não estejam explicitamente fazendo parte dos documentos do projeto;
 Inserção de dados nas bases dos produtos TOTVS, manual ou eletronicamente. A

TOTVS estará, no decorrer da implementação, orientando e transferindo
conhecimentos para o time de projeto da Universidade de Mogi das Cruzes para que
estes executem a alimentação das bases de dados, disponibilizando os layouts e
programas para as referidas importações;
 Instalação de produtos em outras unidades e locais da Universidade de Mogi das

Cruzes que não estejam declaradamente citadas em contrato;
 Reuniões extraordinárias, exceto as de pontos de controle, previstas no projeto;
 Horas gastas em apresentação do trabalho efetuado ou a efetuar para os diversos

níveis da empresa por solicitação da empresa;
 Retrabalhos causados por falta de definição ou capacidade do usuário designado pela

Universidade de Mogi das Cruzes para realização da atividade, ou pela substituição do
mesmo;

44
MIT030 – PLANO DO
PROJETO
 Retrabalhos provocados por problemas no ambiente operacional e em função de
mudanças administrativas que impliquem na alteração dos processos previstos no
início da implementação;
 Retrabalhos provocados por problemas nas atividades de responsabilidade dos

usuários que impliquem na execução de atividades adicionais não previstas no
cronograma;
 Horas em que o consultor da TOTVS - Mit Tecnologia ficou acompanhando a execução

de uma atividade prevista em cronograma, que deveria ter sido executada
previamente à visita do consultor, por um profissional da Universidade de Mogi das
Cruzes;
 Horas de consultor da TOTVS – Mit Tecnologia gastas para execução de atividades que
são de responsabilidade da Universidade de Mogi das Cruzes, tais como abertura e
acompanhamento de Chamados, configuração de hardware e software, atualização de
programas, construção de relatórios no VIEWER, construção de programas
específicos, apoio à infraestrutura.
 Este projeto de implementação não contempla serviços de consultoria de processos,

porém os softwares já contemplam as melhores práticas de mercado;
 Qualquer item não explicitamente descrito neste documento.
Serão consideradas horas improdutivas para o bom desenvolvimento dos Trabalhos,

buscando preservar a relação custo/benefício:
 Todo e qualquer impedimento para execução dos trabalhos ocasionados por atrasos
de atividades de responsabilidade da Universidade de Mogi das Cruzes no
cronograma;
 Falta de recursos de responsabilidade da Universidade de Mogi das Cruzes para

executar as atividades previstas no cronograma;
 Horas de locomoção para a realização de trabalhos em outras unidades da

Universidade de Mogi das Cruzes, nas quais estes trabalhos não estejam previamente
planejados;
 Horas nas quais o consultor da TOTVS ficou aguardando, por quaisquer motivos, a
disponibilização de um profissional da Universidade de Mogi das Cruzes ou recursos
técnicos de hardware ou de software para a execução de atividades pré-programadas
e agendadas em cronogramas.
2.7. Premissas:
São artefatos / influências externas que podem afetar diretamente o progresso ou
sucesso do projeto, ao qual o Gestor de Projeto não tem controle direto. Identificamos as
seguintes premissas para garantir o sucesso deste projeto:
 A metodologia de implementação a ser utilizada será a Metodologia de

Implementação TOTVS (MIT). Toda a documentação será realizada nos padrões
utilizados pela contratada. Caso seja necessária a utilização de metodologia
específica, um orçamento de horas poderá ser apresentado ao cliente.

44
MIT030 – PLANO DO
PROJETO
 Agilidade na aprovação da documentação do projeto tais como, Plano de Projeto, Atas
de Reunião, Levantamentos Complementares e Cronograma, considerando o prazo
apresentado no cronograma, para não afetar o andamento das demais atividades.
 Uma fase da metodologia somente será iniciada após a aprovação formal da fase que
a precede.
 O cliente deve ter capacidade de recuperação de dados, tais como Backup,

processamento paralelo, segurança de dados, plano de contingência, etc.
 Backups e Manutenções de rede da Universidade de Mogi das Cruzes, que venham a

afetar o andamento programado do projeto, deverão ser previamente acordados com
a TOTVS.
 Disponibilidade e alocação dos recursos identificados e listados no plano de projeto.

Comprometimento e claro entendimento dos objetivos e metas do projeto, por todos
os envolvidos (stakeholders). Completo entendimento do fluxo operacional e de
negócio das áreas envolvidas pelos usuários chave, os quais foram identificados pela
Universidade de Mogi das Cruzes e listados neste documento. (ANEXO II – Matriz
resp/III-Stakeholders)
2.8. Limites do projeto (exclusões):

 Não serão realizadas especificações de sistemas e/ou funcionalidades que não
façam parte dos produtos TOTVS e que não tenham sido negociadas na proposta
comercial deste projeto.
 Não será realizada a integração entre programas específicos com os produtos

TOTVS, existentes ou a serem adquiridos após a execução deste projeto.
 Não serão desenvolvidos relatórios específicos para o cliente, a não ser mediante
negociação de novas horas para esta tarefa.
 Não será realizada a migração de versão de outros produtos TOTVS que já estejam
em operação no cliente. Durante a execução do projeto, será definida a versão
que será implantada no cliente, evitando conversões durante o projeto.
 Qualquer item não explicitamente descrito neste documento ou não relatado na

modelagem de processos deverá ser negociado entre cliente e TOTVS, avaliando a
necessidade de horas para novas implementações e/ou alterações nos processos
e suas configurações.
2.9. Controle e gerenciamento das informações do projeto:

Todos os documentos deverão ser impressos e assinados em duas vias, originais, e
armazenados na pasta do projeto. Estes documentos também poderão ser
disponibilizados em arquivos eletrônicos, porém sem as devidas assinaturas que
formalizaram os aceites. Uma via deverá ser mantida pelo cliente e a outra via será
armazenada pela equipe TOTVS.

44
MIT030 – PLANO DO
PROJETO
2.10. Registro das alterações do Plano do Projeto:

Registro das Alterações
Data Mudança Motivo Aprovado por:
3. Gerenciamento do Escopo
3.1. Declaração do Escopo.

O Escopo do projeto foi documentado e validado através das Especificações de Processos,
documentos os quais foram assinados pelos envolvidos no levantamento de processos. A
Especificação Técnica de cada produto também deverá ser considerada para determinar
as funcionalidades disponíveis nos sistemas e registrar quais serão de fato implantadas
de acordo com as necessidades reais do cliente.
Escopo em Anexo IIII.
Descrição do escopo dos produtos
Processo / Módulo Definido por: Aprovado por:

Vertical / Frente
de Trabalho
Entradas Compras Celso Adilson de Oliveira
Entradas Estoque Antônio Adilson de Oliveira
Entradas Faturamento Elias/Francisco Adilson de Oliveira
Entradas Financeiro Elias Adilson de Oliveira
Entradas Contabilidade Francisco Adilson de Oliveira

44
MIT030 – PLANO DO
PROJETO
Entrega Descrição
Fase de Iniciação Termo de Abertura

Coordenador do projeto definido
Plano de Atividades
Apresentação de gestão de projetos
Fase de Modelagem dos processos validados
Planejamento Declaração de escopo do projeto validado
Plano de projeto validado
Fase de Execução Produto parametrizado
Usuários chave capacitados
Protótipos realizados e validados
Atividades iniciais acompanhadas
Primeiros fechamentos acompanhados
3.2. Dicionário da EAP.

44
MIT030 – PLANO DO
PROJETO
ID da EAP Pacote de Descrição Critérios de Aceitação

Trabalho
1.1 Contrato Inicial Conclusão da negociação Proposta comercial e

comercial com a aprovação da contrato assinado
proposta comercial pelo cliente
(incluindo condições
faturamento, despesas e
deslocamento previsto para os
recursos).
1.2 Escopo Descrição dos processos e Proposta comercial

Preliminar módulos na Proposta assinada
Comercial, considerando
também as demandas de
treinamento dos usuários do
cliente.
1.3 Expectativas Alinhamento das expectativas Termo de Abertura e ata

Alinhadas junto ao cliente, com presença da transição assinados
do Executivo da Conta e dos
principais “interessados” do Plano de atividades ou
cliente. cronograma inicial
2.1 Levantamento Levantamento e documentação Especificação de Processo

de Processos os processos de cada área,
definindo os processos
propostos para a
implementação de cada
módulo do ERP. A análise da
infraestrutura necessária é
realizada para confirmar o
ambiente do cliente e solicitar
eventuais modificações.
O levantamento consiste em
entrevistas presenciais e
documentação dos processos
nos padrões da MIT. O escopo
detalhado fundamentará as
demais áreas de planejamento
do projeto, além de confirmar
as necessidades de
customização identificadas e
que serão repassadas à Fábrica
de Software.
2.2 Plano do Projeto Definição e planejamento da Plano do Projeto validado

estratégia necessária para

44
MIT030 – PLANO DO
PROJETO
alcançar os objetivos do e assinado
projeto, determinando as
entregas do escopo contratado Estimativa de horas
pelo cliente. destinadas à
customização (quando
Todos os pontos cruciais serão houver)
abordados neste documento:
critérios de qualidade, regras
de comunicação, custos
previstos, estimativas de
prazos, papéis e
responsabilidades,
organograma do projeto,
premissas e restrições, etc.
2.3 Estimativas De acordo com o escopo Cronograma do Projeto

Realistas detalhado e a estimativa de
trabalho dos especialistas,
define-se o cronograma de
implementação, considerando
a disponibilidade dos recursos
do projeto.
É importante programar o
treinamento padrão dos
usuários do cliente antes do
início da implementação,
ambientando-os quanto ao uso
dos sistemas que serão
implantados.
3.1 Sistemas Instalação do sistema (módulos

Instalados e bases de dados) realizada
pela equipe técnica do cliente,
com posterior análise da
equipe TOTVS quanto à
infraestrutura solicitada.
3.2 Processos Parametrização e configuração Validação de processos

Parametrizados dos processos especificados no assinada pelo usuário
levantamento e validados pelo chave a cada processo
cliente, além de realização dos simulado e validado
cadastros necessários,
definição de perfis, acessos, Validação da entrega
usuários, eventuais migrações modular assinada pelo
de dados, testes, simulações gerente de projetos do
dos possíveis cenários da cliente
rotina do cliente, etc.
As tarefas serão
compartilhadas entre a equipe
TOTVS e os usuários do cliente,
visando o cumprimento do

44
MIT030 – PLANO DO
PROJETO
prazo e custo definidos para o
processo de implementação.
3.3 Protótipos Validação da integração entre Validação de processos

(Testes os módulos do ERP, além de assinada pelo usuário
Integrados ou integrações com outros chave a cada processo
Individuais) produtos TOTVS, de terceiros simulado e validado
ou customizações, verificando
a comunicação entre as áreas Lista de Tarefas para
e os resultados dos processos Entrada em Produção
compartilhados entre as
mesmas.
É importante validar a rotina

do cliente considerando toda
sua cadeia de processos,
garantindo que os resultados
obtidos correspondem à
necessidade identificada no
cliente.
3.4 Capacitação Durante a simulação dos Validação de Capacitação

processos, os usuários chave
serão responsáveis por
compreender a nova rotina no
sistema e posteriormente
capacitar os demais usuários
nos processos implantados.
A capacitação dos usuários

envolvidos é premissa para a
entrada em produção e a
equipe TOTVS avaliará os
usuários do cliente quanto à
sua autossuficiência.
3.6 Acompanhamen Acompanhamento das Plano de Virada aprovado

to da Produção atividades iniciais e primeiros
fechamentos, conforme Lições Aprendidas
programado no cronograma do (preenchimento iniciado)
projeto. Se necessário, uma
nova proposta comercial
deverá ser apresentada para
prorrogar a permanência da
equipe TOTVS no
acompanhamento das rotinas
do cliente.
4.1 Encerramento Formalização do encerramento Check list de

do Projeto do projeto, apresentando os Encerramento
resultados obtidos, discutindo
os desvios ocorridos, Termo de Encerramento
fornecendo dados e

44
MIT030 – PLANO DO
PROJETO
experiências sobre o
gerenciamento de projetos.
Transição do atendimento do
cliente para o suporte,
comunicando ao Comercial
sobre a conclusão do projeto e
demandas em potencial no
cliente.
4.2 Encerramento Formalização do encerramento Ata reunião com

do Contrato do contrato, verificando encerramento do projeto
quaisquer pendências
administrativas referente ao
serviço contratado.
3.3. Plano de Carga

O plano será utilizado conforme segue:
 A equipe deve utilizar este processo para comunicar a estratégia para o sucesso da
conversão/carga dos dados de legado ou outras fontes de informações para o novo
sistema.
 A equipe deve utilizar este processo como um guia para a montagem dos roteiros de
carga. Todos os membros da equipe devem entender e seguir a mesma estratégia.
 O gestor deve utilizar este processo para entender como a carga de dados se
comunica com a estratégia dos demais planos, e como ela pode impactar no esforço
global de projeto.
Estratégia
O principal objetivo da carga de dados é o de converter (seja via digitação, APIs,
programas de conversão, etc.) a herança e outros dados relacionados com a empresa
para os produtos TOTVS.
Usando os roteiros de carga de dados como guia, os usuários chaves ou equipe técnica
irão realizar as cargas necessárias e homologação, garantindo assim que a solução está
pronta para as simulações e testes.
O cliente será o responsável pela conferência e homologação dos dados carregados ou

digitados.
São fatores críticos de sucesso para a carga de dados:
 Arquitetura técnica bem definida

 Requisitos, aplicação e configurações estáveis.
 Participação do usuário chave, como parte da equipe de conversão, ajudando a
garantir que tudo está sendo carregado conforme a necessidade e disponibilidade
 Disponibilidade de APIs
 Identificação antecipada e conclusão de traduções, limpeza e transformações dos
dados

44
MIT030 – PLANO DO
PROJETO
Gestão da Carga de Dados
A carga de dados será realizada na etapa G – Parametrização e Cadastros, utilizando as
orientações descritas nos roteiros de carga.
Os resultados das cargas serão registrados no Roteiro de Carga na coluna Status.
Critérios de Aceitação
A aceitação será realizada através da assinatura do Gerente de Projetos da Universidade
de Mogi das Cruzes no documento de validação de importação de cadastros. Lembrando
que é função do cliente a validação dos dados e homologação.
Cronograma
O cronograma integrado do projeto será disponibilizado ao Gerente de Projetos da
Universidade de Mogi das Cruzes e semanalmente atualizado.
3.4. Plano de Testes

Definir o Plano de Testes do projeto Implantação Protheus, tem como objetivo registrar a
forma que serão realizados os testes, o que será testado e também documentar aspectos
globais relacionados a testes. Isto possibilitará uma bem-sucedida coordenação e
condução de testes no projeto.
A estratégia analisa as características do projeto e da solução a ser implantada, a fim de

orientar os esforços de testes e validação. O plano de testes irá influenciar, inclusive,
tarefas relacionadas à preparação para os testes (carga de dados, coleta de documentos,
etc.).
Estratégia
Neste projeto, os testes serão guiados pelos seguintes princípios:
 Testes e validações serão realizados em todos os produtos

 Os testes devem ser repetidos em caso de erro
 Os testes serão executados pelos usuários chaves com o acompanhamento do
consultor
 Os problemas encontrados devem ser registrados nos roteiros de protótipo para
correção e repetição dos testes
 Testar cada função de negócio com base nos dados previamente preparados,
repetindo exaustivamente para assegurar o correto funcionamento deles.
 Os testes serão realizados na estação Cliente.
 O sistema será avaliado com volumes variados na base de dados. Considerando que a
eficiência dos testes está ligada ao número de registros a serem processados
 Executar o sistema com vários usuários acessando-o simultaneamente e verificar os
problemas de tratamento das informações e acesso.
 Executar o sistema nas diversas condições previstas de ambiente de campo,
determinando a viabilidade de performance na prática.
 O objetivo em todas as fases de testes é verificar se o sistema está apto para fins
comerciais
 O objetivo de projetar e executar um teste consiste em encontrar erros

44
MIT030 – PLANO DO
PROJETO
 Usando roteiros de testes como guia, os usuários irão realizar os testes necessários e
homologação, garantindo assim que a solução está pronta para entrar em produção
A lista a seguir identifica o que será avaliado durante os testes:
 Negócio/funcionalidade/etapas do processo empresarial

 Usabilidade: coerência, facilidade de uso
 Desempenho: resposta tempos, volume, stress (carga de ensaio)
 Segurança: acesso permissões de segurança de dados
 Operabilidade, testado usando cenários derivados de procedimentos operacionais
 Conversão de dados e qualidade dos dados
 Acesso simultâneo
Os usuários devem ser encorajados a realizar os protótipos isolados independentes

depois de efetuadas as parametrizações, fornecendo feedback para os consultores,
refinando desta forma suas necessidades. Desta forma, a execução do plano de testes
torna-se uma tarefa simples, uma vez que o sistema já foi testado previamente e
validado pelo usuário chave como parte do processo de execução.
Gestão dos Testes

Os testes serão efetuados na etapa H - Protótipos, utilizando os cenários descritos no
MIT045 – Roteiro de Protótipo.
Os resultados dos testes serão registrados no MIT045 – Roteiro de Protótipo na coluna
situação.
Os problemas encontrados serão registrados na MIT006 – Lista de Tarefas e Pendências.

Caso possível, deve ser preenchida uma recomendação de solução. O usuário chave
efetuará as correções necessárias com o acompanhamento do consultor. Para os casos de
defeitos de sistema devem ser abertos chamados para correção.
Critérios de Aceitação
Resultados de testes são aceitos sempre que o sistema atua de uma forma que satisfaça
as necessidades de negócios. A fim de alcançar uma medida de negócios de adequação
ao uso, a ênfase na experimentação e validação é colocada a questão de saber se o
processo empresarial, com o apoio do sistema, cumpre os objetivos estabelecidos.
Em caso de ocorrência de erros críticos, estes devem ter a solução imediata. – o esforço
de correção deve ser planejado com o Coordenador do Projeto TOTVS. Um erro será
considerado crítico se inviabilizar o sistema de atender algum requisito essencial para
continuidade dos trabalhos dos usuários.
Cronograma
O cronograma integrado do projeto será disponibilizado ao Gerente de Projetos da
Universidade de Mogi das Cruzes e semanalmente atualizado.

44
MIT030 – PLANO DO
PROJETO
3.5. Processo para verificar o escopo ao final das entregas para aceite
do cliente:
A verificação das entregas será realizada através das Validações de Processos (modelo
MIT008 – Validação de Processos), onde o cliente formalizará a simulação realizada e a
conferência dos resultados obtidos ao final da implementação de cada processo.
3.6. Regras para solicitar mudanças de escopo:

Qualquer alteração de escopo deve ser submetida ao Comitê do Projeto para aprovação.
As alterações serão avaliadas considerando o prazo, custo benefício e impacto nas
demais condições do projeto. Após a aprovação, o prazo e o custo do projeto serão
revistos, a fim de contemplar a nova demanda.

44
MIT030 – PLANO DO
PROJETO
3.7. Processo para priorizar solicitações de mudanças de escopo:

44
MIT030 – PLANO DO
PROJETO
Alçadas e prioridades:
 Mudanças com prioridade 0 (zero) – Urgente, com alto impacto no projeto e em

outras áreas sobre as quais o gerente de projeto não tem autonomia. Requerem uma
ação imediata por parte do gerente do projeto, o qual deve acionar imediatamente o
patrocinador.
 Mudanças com prioridade 1 (um) – Urgente. Requer uma ação imediata por parte
do gerente do projeto, independente das reuniões de controle previstas, acionando
imediatamente o patrocinador no caso de necessidade de autorizações financeiras
fora da alçada do gerente de projetos.
 Mudanças com prioridade 2 (dois) – Urgente, mas sem impacto significativo nos
custos e nos prazos do projeto. Requer um planejamento da ação por intermédio de
terceiros ou de equipes que, a princípio, tenham disponibilidade, uma vez que
agregam valor ao sucesso do projeto.
 Mudanças com prioridade 3 (três) – Não impactantes ou urgentes. Mudanças de

prioridade três podem ser implementadas por terem influência no sucesso do projeto.
Anexo: Modelo de fluxo para controle das mudanças (escopo e qualidade).

44
MIT030 – PLANO DO
PROJETO
4. Gerenciamento do Cronograma
4.1. Cronogramas detalhados com base na lista de atividades.
O cronograma completo do projeto segue anexado ao Plano do Projeto (Anexo IV)

contendo o primeiro planejamento definido para o projeto. Qualquer alteração na
programação das atividades e seus respectivos recursos serão comunicados ao cliente,
solicitando sua aprovação e/ou formalizando o novo planejamento proposto para o
projeto.
Segue a baixo o cronograma macro das atividades.

44
MIT030 – PLANO DO
PROJETO
4.2. Regras para solicitação de mudanças, ações corretivas ou

preventivas a partir da análise de variação do cronograma:
Processo, regras e critérios para mudanças nos prazos (alçadas e prioridades), como no
exemplo abaixo:
 Atrasos com prioridade 0 (zero) – Urgente e de alto impacto no projeto e com

soluções inicialmente não identificadas. Requerem uma ação imediata por parte do
gerente do projeto, que deve acionar imediatamente o patrocinador para discussão e
análise.
 Atrasos com prioridade 1 (um) – Urgente. Requer uma ação imediata por parte do
gerente do projeto, independente das reuniões de controle previstas, acionando as
medidas de recuperação de prazos disponíveis, tais como o Fast Tracking, ou
Crashing, o trabalho em horas-extras, banco de horas e mutirão. Os custos que por
ventura decorrerem dessas ações deverá ser alocado nas reservas gerenciais.
 Atrasos com prioridade 2 (dois) – Requerem um replanejamento das atividades

futuras, uma vez que o projeto ainda não completou 25% de conclusão.
 Atrasos com prioridade 3 (três) – Pequenos se comparados com a duração do

projeto – Podem ser remanejados sem necessariamente ser preciso replanejar ou
acionar algum tipo de mecanismo de recuperação.
Anexo: Modelo de fluxo para controle das mudanças nos prazos:

44
MIT030 – PLANO DO
PROJETO
4.3. Reserva de horas para riscos de cronograma (atividades buffers):

Não há reserva de horas para gerenciamento de riscos decorrentes de alteração no prazo
deste projeto. Caso seja necessário, as horas previstas para o projeto serão renegociadas
por alteração ou mudança de escopo será objeto de nova negociação.
5. Gerenciamento da Qualidade
5.1. Métricas e metas de qualidade:
Este documento define o Plano de Qualidade do projeto Implantação Protheus,

identificando como a qualidade da aplicação e dos artefatos envolvidos na
implementação da solução será garantida.
Todas as mudanças no plano de qualidade originalmente aprovado para o projeto deverão
ser requisitadas, avaliadas e aprovadas formalmente, em conformidade com o Sistema de
Controle de Mudanças, para serem implementadas.

44
MIT030 – PLANO DO
PROJETO
5.2. Listas de verificação da qualidade:
A verificação da qualidade será realizada através do cumprimento da Matriz de
Obrigatoriedade da MIT, a qual define os documentos e formalizações necessários no
projeto de acordo com seu nível de complexidade. Todos os documentos gerados no
projeto devem ser assinados pelos devidos envolvidos por parte do cliente.
Artefato/Entrega Responsável Aprovador Registro

es Inspeção
Iniciação
MIT021 – Termo de Patrocinador Comitê Documento

Abertura executivo assinado
Planejamento
MIT030 - Plano de Coordenador Coordenador Documento

Projeto do Projeto do projeto do assinado
TOTVS e cliente /
Coordenador Diretoria e
do Projeto do Gerência do
cliente Cliente
MIT032 – Cronograma Coordenador Coordenador Cronograma
do Projeto do projeto do projeto do assinado
TOTVS e cliente
Coordenador
do projeto do
cliente
MIT033 – Requisitos Coordenador Coordenador Documento
de Entrega do projeto do projeto do assinado
TOTVS e cliente /
do projeto do Gerência do
cliente Cliente.
MIT034 – Matriz de Coordenador Coordenador Documento
Responsabilidades do projeto do projeto do assinado
TOTVS e cliente.
Coordenador
do projeto do
cliente
MIT036 - Matriz de Coordenador Coordenador Documento
Riscos do projeto do projeto do assinado
TOTVS e cliente /
coordenador Diretoria e
cliente Cliente
MIT041- Especificação Analista Coordenador Documento
do Processo do projeto do assinado
cliente /
Diretoria e
Gerência do

44
MIT030 – PLANO DO
PROJETO
Cliente /
Usuário
chave
MIT044 – Analista Coordenador Documento
Especificação de do projeto do assinado
Personalização cliente /
Diretoria e
Gerência do
Cliente /
Usuário
chave
MIT045 – Roteiro Analista Coordenador Documento
Protótipo do projeto do assinado
cliente /
Diretoria e
Gerência do
Cliente /
Usuário
chave
MIT046 – Análise de Analista Coordenador Documento
GAP do projeto do assinado
cliente /
Diretoria e
Gerência do
Cliente /
Usuário
chave
MIT056 – Mapeamento Coordenador Coordenador Documento
Stakeholders de projeto do projeto do assinado
TOTVS e cliente /
de Projetos Gerência do
Cliente Cliente
MIT057 – Estratégia de Coordenador Coordenador Documento
Comunicação de projeto do projeto do assinado
TOTVS e cliente /
de Projetos Gerência do
Cliente Cliente
Execução
Treinamento Analista Coordenador MIT010 – Validação

do Projeto do de Processo
cliente / assinadas
Usuário
Chave
Parametrização e Analista Coordenador MIT010 – Validação
Cadastros do Projeto do de Processo
cliente / assinado.
Usuário
Chave
Validação da Base de Analista Coordenador MIT010 – Validação

44
MIT030 – PLANO DO
PROJETO
Dados do Projeto do de Processo
cliente / assinado.
Usuário
Chave
Simulações por Analista Coordenador MIT045 – Roteiro
Módulo do Projeto do do protótipo
cliente / assinado
Usuário
Chave
Simulações por Analista Coordenador MIT010 – Validação
Processo do Projeto do de Processo
cliente / assinado.
Usuário
Chave
Plano de Virada Coordenador Coordenador MIT054 – Plano de
do projeto do projeto do Virada assinado.
TOTVS e cliente /
cliente. Cliente
Encerramento
MIT062 – Termo de Coordenador Coordenador Documento

Encerramento do Projeto do Projeto do assinado
TOTVS cliente /
Diretoria e
Gerência do
Cliente
MIT060 – Lições Coordenador Gestor de Documento
Aprendidas do Projeto Portfólio de assinado
TOTVS Projetos
TOTVS
MIT065 – Transição do Coordenador Coordenador Documento
Projeto do Projeto do Projeto do assinado
TOTVS cliente /
Diretoria e
Gerência do
Cliente
Monitoramento e Controle
Acompanhamento do Coordenador Coordenador Ata de reunião

Projeto (MIT007 e do Projeto do Projeto do assinada.
MIT008) TOTVS cliente /
Diretoria e
Gerência do
Cliente
MIT005 – Ata de Coordenador Gestor do Documento
Reunião do Projeto projeto do assinado
TOTVS cliente /
Diretoria e
Gerência do
Cliente

44
MIT030 – PLANO DO
PROJETO
MIT031 – Solicitação Qualquer papel Comitê Documento
de Mudança executivo assinado
A complexidade deste projeto define os seguintes documentos como requisitos para o

controle e verificação da qualidade do projeto:
Nível de Complexidade
Documento MIT
1 2 3 4 5
Controle
MIT005 - Ata de Reunião x x x x x
MIT006 - Lista de Tarefas e Pendências x x x x x
MIT008 - Acompanhamento de Projeto x x x x x
MIT010 - Validação de Processos x x x x x
Iniciação
MIT021 - Termo de Abertura x x x x x
MIT023 - Apresentação Gestão de Projetos x x x
Planejamento
MIT030 - Plano do Projeto x x x
MIT031 - Solicitação de Mudança x x x
MIT032 - Cronograma do Projeto x x x x x
MIT034 - Matriz de Responsabilidades x x x
MIT036 - Matriz de Riscos x x
MIT041 - Especificação de Processos x x x x
MIT044 - Especificação de Personalização x x x
MIT045 - Roteiro de Protótipo x x x
MIT046 - Analise de GAP x x x
MIT047 - Apresentação do Plano do Projeto x x x
MIT056 - Mapeamento Stakeholders x
MIT057 - Plano de Comunicação x
Execução
MIT054 - Plano de Virada x x x
Encerramento
MIT060 - Lições Aprendidas x x x
MIT061 - Check List Encerramento x x x
MIT062 - Termo de Encerramento x x x x x
MIT063 - Declaração de Recusa do
Encerramento x x x x
MIT065 - Transição do Projeto x x x x
5.3. Mudanças, ações corretivas e ações preventivas nos padrões de

qualidade estabelecidos e aprovados:
 Políticas de encaminhamento de problemas e ações corretivas

44
MIT030 – PLANO DO
PROJETO
Todos os problemas e ações corretivas deverão ser comunicados pelo Gerente de Projetos
da Universidade de Mogi das Cruzes ao Coordenador de Projetos MIT, a fim de garantir a
devida formalização das pendências e um controle detalhado sobre a qualidade das
entregas. A Lista de Tarefas e Pendências será utilizada para registro e acompanhamento
dos itens notificados.
6.4. Regras para medições de controle da qualidade das entregas:

 As métricas de qualidade apresentadas na tabela abaixo indicam os parâmetros para
a avaliação do resultado de inspeções e auditorias.
Métrica Possíveis Interpretações Dicas para

valores medição e
análise
Nr. Não 10 % No decorrer da iteração Avaliar o produto

Conformida 0 ao final da podem ser apontadas seguindo a
des iteração algumas não especificação da
conformidades que norma utilizada.
devem ser corrigidas até
o final da iteração.
Qualquer valor diferente
de zero indica a
necessidade de reajustar
o item auditado de modo
a garantir sua qualidade
Prazo de 10% Deve ser avaliada a Avaliar o número
Entrega variação entre o número de dias das
de dias do projeto e o entregas dos
número de dias em marcos do
atraso. projeto, com base
nos baselines
setados no
cronograma.
Atendiment 100% Será levando em Avaliar se foram
o do Escopo consideração o banco de atendidos todos
requisitos e a os requisitos do
homologação final do projeto com base
produto. no parágrafo de
escopo funcional
no plano de
projeto.
5.5. Processo para registrar erros e problemas:

As pendências, problemas e erros serão registrados através de 3 formatos diferenciados:
1. Abertura de Chamados / Ocorrências: De acordo com eventuais erros detectados
no produto, as solicitações de correção serão geradas pela equipe do projeto,
formalizando o “bug” identificado durante a implementação ou simulação dos
processos. O status dos mesmos e a previsão de liberação da correção serão
acompanhados pela equipe, alinhando esta pendência ao andamento do projeto.

44
MIT030 – PLANO DO
PROJETO
O número do chamado / ocorrência será informado ao cliente para que o mesmo
possa acompanhar a solicitação diretamente com o Suporte TOTVS.
2. Atas de Reunião: Durante os posicionamentos do projeto, o gerente de projetos da
Universidade de Mogi das Cruzes irá reportar todos os pontos críticos
apresentados durante determinado período. A ata registrará as decisões tomadas
e ações pendentes, bem como seus devidos responsáveis e prazos estimados.
Estas ações irão alimentar a Lista de Tarefas e Pendências do projeto.
3. Lista de Tarefas e Pendências: Todos os itens que exigem acompanhamento da
equipe MIT para realizar as entregas previstas serão registrados e acompanhados
através desta listagem, que será apresentada ao cliente para demonstrar a
evolução das pendências detectadas. Os chamados / ocorrências também serão
mencionados para que o cliente identifique os itens de responsabilidade do
Desenvolvimento / Suporte TOTVS, diferenciando das pendências relativas ao
trabalho da equipe de implementação.
6. Gerenciamento do Pessoal
6.1. Matriz de atribuição de responsabilidades:

Os papéis e responsabilidades serão definidos na Matriz de Responsabilidades, indicando
a atuação de cada “função” em relação às atividades previstas para o projeto. A matriz
segue como anexo a este plano.
6.2. Funções, autoridade, responsabilidade e competências necessárias

para os membros do projeto:
Funções e Responsabilidades dos Integrantes do Comitê – Time Cliente:

 Patrocinador (Sponsor):
o Terá poder de veto das decisões entre os Gerentes do Projeto e Usuários
Chave.
o Efetuará aprovação dos recursos necessários para melhorar produtividade e
margens.
o Participará, por intermédio de reuniões do Comitê Executivo do Projeto, para
atestar o andamento do projeto.
o Terá poder de decisão para responder por todas as questões inerentes ao
projeto – voto de desempate no caso de algum desentendimento/discordância.
 Gerente do Projeto:
o Profissional responsável pelo Gerenciamento do Projeto por parte do Cliente, e
corresponsável por todas as definições, metas e prazos, em conjunto com o
Gerente do Projeto da TOTVS, Líderes de processos e Usuários Chave.
o Terá a responsabilidade de manter o Comitê do Projeto informado sobre o
andamento do projeto.
o Terá autonomia para decisões de caráter estratégico.
o Sua participação deverá ser de, no mínimo, 75% da sua carga horária.
 Líderes de Processo:
o Terá conhecimentos satisfatórios sobre todos os processos de seu
departamento, assim como autonomia para decisões de caráter operacional.
o Terá a responsabilidade de desenvolver alternativas de solução para o projeto.
o Terá participação efetiva na definição e validação do modelo de negócio a ser
implementado e na capacitação para uso do produto.

44
MIT030 – PLANO DO
PROJETO
o Sua Participação será de, no mínimo, 50% de sua carga horária.
 Usuários Chaves:
o Participará efetivamente na definição dos processos, mapa de funcionalidades
e capacitação para uso do sistema.
o Terá conhecimentos satisfatórios sobre todos os processos de seu
departamento.
o Será responsável pela replicação dos treinamentos realizados.
o Sua participação será de, no mínimo, 50% de sua carga horária.
 Usuários Finais:
o Subordinados aos Usuários Chave.
o São operadores do sistema e serão os executores das tarefas internas.
o Sua participação será de, no mínimo, 25% de sua carga horária junto ao
usuário chave.
 Equipe Técnica T.I.:

o Profissionais da área de sistemas totalmente dedicados ao processo de
implementação.
o Serão responsáveis por definir e revisar a estrutura tecnológica e balancear
provedor e usuários.
o Serão os responsáveis técnicos pelo Sistema após a implementação.
o Deverão acompanhar e executar as atividades relacionadas à infraestrutura,
além da administração do ERP (Ambiente, instalações, servidores =
administradores do sistema).
o Sua participação será de, no mínimo, 75% de sua carga horária.
Funções e Responsabilidades dos Integrantes do Comitê – Time TOTVS:
 Gerente do Projeto/Coordenador do Projeto:

o Será o responsável por todo gerenciamento do projeto por parte da TOTVS e
corresponsável por todas as definições, metas e prazos, acordados com o
gerente de projeto do Cliente.
 Analista de Processos (Consultor Especialista):

o É o profissional especialista em regras de negócio. Tem a responsabilidade de
entender os processos da empresa do cliente para “traduzir” os mesmos de
acordo com o escopo negociado com o cliente e conforme as funcionalidades
disponíveis no ERP TOTVS.
o Responsável por assegurar o balanceamento entre as funções do ERP e
necessidades dos processos.
o Responsável por entrevistar os usuários das áreas, registrando os processos
propostos conforme os padrões estabelecidos pela MIT. Toda a documentação
será validada e aprovada formalmente pelo cliente.
o Em seguida, este analista irá documentar os processos “tecnicamente”,
fornecendo instruções para que a implementação seja realizada de acordo com
o processo proposto, adequando/configurando o sistema segundo as
necessidades identificadas no levantamento.
 Analista de Implementação:

44
MIT030 – PLANO DO
PROJETO
o Responsável por configurar o sistema conforme o escopo aprovado pelo
cliente, compreendendo a documentação elaborada pelo Analista de
Processos.
o Responsável pela implementação dos processos contratados pelo cliente.
Entre as principais atividades, podemos destacar: análise das integrações
entre os módulos, parametrização do sistema, simulação dos processos e
capacitação dos usuários chave.
 Executivo/Gestor de Atendimento e Relacionamento:

o Será responsável pela oferta dos produtos e serviços, sendo também um canal
de comunicação entre as partes, para questões comerciais.
o Responsável pela negociação das condições comerciais da proposta de
serviços.
o Acompanhará gerencialmente todas as ações junto aos clientes.
 Arquiteto de Solução:
o Responsável pela avaliação e desenho de soluções a serem implementadas, de
acordo com as necessidades apontadas pelo cliente.
o Atua principalmente na fase de pré-projeto e na definição de novas frentes de
trabalho, quando necessário.
6.3. Organograma do projeto:

Organograma referente a Universidade de Mogi das Cruzes:
Organograma referente a TOTVS – Mit Tecnologia:

44
MIT030 – PLANO DO
PROJETO
6.4. Necessidade de treinamento identificada:

Durante a negociação comercial, as necessidades de treinamento para equipe do cliente
no projeto foram identificadas. O número de vagas por módulo segue abaixo e é
importante programar estes treinamentos para que ocorram antes do início das
atividades de implementação dos processos, possibilitando o contato prévio dos usuários
com os novos sistemas.
Número de Considerado
Treinamentos Dedicados
Vagas na Proposta?
Compras 2 Sim
Estoque 2 Sim
Financeiro 2 Sim
Faturamento 2 Sim
Contabilidade 2 Sim
Total 12
(*) As vagas não contempladas na proposta comercial original deverão ser negociadas
com o Executivo de AR responsável pela conta. Entretanto, vale ressaltar que a
capacitação dos usuários é fundamental para o sucesso do projeto de implementação.
7. Gerenciamento das Comunicações
7.1. Planejamento das comunicações:
Processos do Gerenciamento das Comunicações

44
MIT030 – PLANO DO
PROJETO
O Plano de Comunicação registra os procedimentos necessários para garantir que a
informação gerada pelo projeto seja reunida, gerenciada e distribuída de maneira precisa
e adequada entre seus participantes.
Serão reconhecidos como processos formais de comunicação para este projeto:
Documentos e relatórios previstos na Metodologia de Implementação TOTVS – MIT e
outros documentos e relatórios de apoio definidos pela em comum acordo pela TOTVS e
cliente;
 E-mails (grupos de e-mail criados pela Universidade de Mogi das Cruzes);
 Reuniões (registradas em ata).
Todas as mudanças no processo de comunicação originalmente aprovado para o projeto
deverão ser requisitadas, avaliadas e aprovadas formalmente, em conformidade com o
Sistema de Controle de Mudanças, para serem implementadas.
7.2. Formato e regras para comunicar desempenho do projeto:
Principais Eventos de Comunicação

Os principais eventos de comunicação previstos para o projeto são:
Reunião de Abertura do Projeto (Kick off)
Oficializar o início do projeto, demonstrando as

transformações que serão ocasionadas pelo mesmo.
Objetivo Integrar a equipe do cliente e repassar conceitos básicos
de gestão de projetos em busca de um alinhamento
contextual para o projeto de implementação do ERP.
Coordenador do Projeto TOTVS e Coordenador do Projeto
Responsável
do cliente
Patrocinador, coordenador de projetos TOTVS, coordenador
de projetos cliente, futuros componentes do Comitê de
Pessoas Envolvidas
Projeto (gestores das áreas, líderes de processo e usuários-
chave).
Apresentação com a participação dos principais
Método interessados, afetados e envolvidos no projeto,
considerando os recursos do cliente e outras organizações.
No início do projeto, após alinhamento e preenchimento do
Frequência
termo de abertura.
Convocação 1 semana antes da reunião, por intermédio de e-mail
Definido pelo responsável pela convocação (sugestão: 2
Duração
horas)
De acordo com o porte do evento, verificar disponibilidade
Local
de sala no próprio cliente.
Observações Registrar participantes presentes
Reuniões do
Comitê Executivo (Estratégico) do Projeto
Comunicação e avaliação do andamento do projeto e
Objetivo definição de ações que exijam decisão por parte do comitê
executivo do projeto

44
MIT030 – PLANO DO
PROJETO
Reuniões do
Comitê Executivo (Estratégico) do Projeto
Coordenador do Projeto TOTVS e Coordenador do Projeto
Responsável
do cliente
Pessoas Envolvidas Participantes do Comitê do Projeto
Reunião com o comitê, baseada no relatório de
Método acompanhamento do projeto e análise de requisições de
mudança no projeto
A cada 15 dias, inseridas na pauta das reuniões de
Frequência
diretoria do cliente
Calendário formal de reunião de acompanhamento
Convocação divulgado pelo comitê e agendamento via correio
eletrônico.
Duração 1 hora.
Local Sala do Projeto (no cliente)
Nesta reunião devem ser discutidas e aprovadas, ou
reprovadas, as solicitações de mudança de escopo do
Observações
projeto, considerando o impacto nas demais variáveis do
projeto (especialmente custos).
Reuniões de Alinhamento da Equipe TOTVS

Alinhar os trabalhos da equipe para que atuem de maneira
Objetivo
integrada durante todo o projeto
Responsável Coordenador do Projeto TOTVS
Pessoas Envolvidas Analistas de Processos e de Implementação
Reunião presencial com a equipe de implementação,
Método alinhando pontos críticos, avaliando mudanças necessárias
e revisando as pendências do projeto.
Frequência Quinzenal
Convocação Via e-mail
Duração Sugestão: 2 horas
Local Sala do projeto (no cliente)
Utiliza-se toda a documentação gerada até o momento no
intuito de nivelar e compartilhar o conhecimento dos
Observações
consultores do projeto e também a gerência, apontando as
possíveis mudanças de escopo ou riscos identificados.

44
MIT030 – PLANO DO
PROJETO
Reunião de Definições Globais
Definir junto com os usuários chave de cada uma das áreas

de negócio as informações que farão parte dos cadastros
mestres dos produtos TOTVS, em conformidade com os
Objetivo processos/fluxos propostos elaborados, ou seja, devem ser
definidos os parâmetros gerais do sistema com vistas a
atender os processos que foram definidos e aprovados com
o cliente.
Responsável Gerente do projeto
Pessoas Envolvidas Usuários chave das áreas de negócio
Método Reunião para tomada de decisão
Freqüência Uma reunião ao final da fase de fluxos propostos
Duração 3 horas
Local Sala do projeto (no cliente)
Será feita uma rodada de duas reuniões antes desta para
Observações
os consultores prepararem o material a ser apresentado
Reunião de Aprovação do Planejamento

Validação do Plano de Projeto com o cliente, apresentando
Objetivo o planejamento de cada área de conhecimento e
formalizando as expectativas do cliente.
Responsável Coordenador de Projetos TOTVS
Comitê do Projeto, incluindo a participação do

Pessoas Envolvidas
patrocinador.
Apresentação dos tópicos do plano, esclarecendo como

Método cada área será gerenciada e quais são as condições de
realização do projeto.
Freqüência Uma reunião ao final da etapa de planejamento
Duração 4 horas
Local Sala do Projeto (no cliente)
Todas as revisões solicitadas deverão ser registradas e
atualizadas no plano de projeto até que se obtenha uma
Observações versão final aprovada pelo cliente, dando por encerrada
esta fase e autorizando o início da fase de execução do
projeto.
7.3. Processo para gerenciar as comunicações com as partes

interessadas:
Para garantir a objetividade, foco e eficácia nas comunicações, especialmente através de
correio eletrônico, sugerimos as seguintes regras:

44
MIT030 – PLANO DO
PROJETO
 Qualquer solicitação referente ao projeto, especialmente quanto a mudanças de
escopo, deverá ser encaminhada e negociada com o Coordenador de Projeto
TOTVS. Os analistas não poderão tomar sozinho quaisquer decisões que possam
porventura impactar no planejamento do projeto e na integração entre os
processos implantados.
 Os momentos destinados às reuniões deverão ser rigorosamente cumpridos para
garantir o melhor aproveitamento das agendas dos recursos da equipe TOTVS.
 Qualquer mudança na agenda da equipe por indisponibilidade do cliente para
atendimento ou outro motivo deverá ser comunicada com antecedência mínima
de 24 horas ao Coordenador de Projetos MIT, evitando o deslocamento
desnecessário do recurso ao ambiente do cliente.
8. Gerenciamento dos Riscos

A TOTVS invariavelmente procura oferecer o máximo de segurança nos projetos de
implementação de seus produtos. Com este objetivo, foi criada a metodologia de
implementação TOTVS (MIT), uma vez que procuraremos oferecer o mesmo nível de
qualidade de serviços para a efetiva aplicação dos nossos produtos, reconhecidamente
com tecnologia de classe mundial.
Entretanto, qualquer organização, independentemente de seu tamanho e da
profundidade das mudanças nos projetos de implementação de softwares de gestão
empresarial, deve considerar os fatores envolvidos no mesmo, principalmente aqueles
relativos aos recursos humanos, aspectos organizacionais, cultura e os reflexos no
planejamento e nas operações da empresa, entendendo-se sempre que há uma clara
variação entre a situação corrente e os novos patamares planejados por esta
organização, como resultante deste processo de mudança. O que se deve admitir como
definitivo é que este projeto gera mudanças, alterações dos processos, mudanças nos
papéis dos colaboradores, modificação nos níveis de responsabilidade e, principalmente,
alteração dos limites entre os vários departamentos e estrutura da organização.
Perante estas expectativas, o Comitê executivo e os gestores do projeto, devem fazer
repetidas avaliações e acompanhamento dos níveis de risco da organização e do projeto.
Neste ponto, o principal destaque é acompanhar e avaliar o nível de aderência e evolução
que o projeto está permitindo para a empresa. Para tanto, a Organização deve estar
preparada para, sempre que necessário, ajustar não somente os processos, mas também
suas políticas e prover o crescimento humano, técnico e profissional de seus recursos,
ajustando-os para a nova realidade e para as novas necessidades, expectativas e metas
da empresa, visando, com isso, atingir o sucesso da implementação, sem os quais o
projeto poderá ampliar seu nível de risco.
Com esta intrínseca ligação, a TOTVS reconhece a importância do Gerenciamento dos
Riscos e, por isso, disponibiliza a metodologia para seu gerenciamento vinculado à sua
metodologia.
O que é o risco?
O gerenciamento de riscos do projeto é um processo sistemático de identificar, analisar,

responder e acompanhar os riscos do projeto.
Devem ser tratados todos os elementos do projeto: organização, pessoas, processos,
ambiente e tecnologia;
O gerenciamento de riscos deve ser aplicado durante todo ciclo de vida do projeto;
Além disso, a TOTVS indica como princípios:

 Como a mudança em projetos é tida como certa, a TOTVS e a Universidade de Mogi
das Cruzes farão o monitoramento constante da implementação e respeitarão o
“Processo de Controle de Mudanças”, o qual parte integrante do Plano de projeto.

44
MIT030 – PLANO DO
PROJETO
 Uma vez identificados, a comunicação dos riscos deve ser feita imediatamente aos
membros do projeto e a todos os demais envolvidos, tais como os membros do
comitê e patrocinadores. Será responsabilidade do gerente de projeto a efetiva
realização desta comunicação, a qual deve ser feita utilizando-se o padrão de
documentação do projeto, adicionando-se a respectiva planilha de riscos com a
forma de mitigação e o respectivo plano de ação.
 A apuração dos riscos, sua análise e seus planos de ação, devem ser insumos para
as lições apreendidas durante o projeto e devem ser reutilizados nas análises de
riscos adicionais e complementares durante todo o projeto, ou seja, no
desenvolvimento de novas análises, as anteriores devem ser revistas e avaliadas a
efetividade das ações anteriormente propostas.
 Compartilhe a responsabilidade dos riscos e dos planos de ação com toda a equipe
de projeto. Ninguém é proprietário exclusivo de um risco, pois a responsabilidade é
de todo o time. Algumas pessoas até podem ser escaladas para tomar ações
mediante riscos identificados, mas os riscos são compartilhados entre todos.
Fator de grande importância deve ser dado à comunicação dos riscos para a equipe do
projeto e com os patrocinadores do mesmo. Sempre que envolvemos o time, a solução
será mais facilmente identificada. Lembre-se que as pessoas têm sua estima elevada
quando são chamadas para participar e decidir. Com isto, você estará compartilhando as
responsabilidades nos resultados do projeto.
Estratégia para Gerenciamento dos Riscos

 Elevado compromisso entre a TOTVS e a Universidade de Mogi das Cruzes para a
eliminação ou, quando isto não for possível, a minimização do risco, uma vez que
admitir a não ação sobre o mesmo, claramente levará o projeto a não ser concluído
no prazo e na qualidade planejada.
 A credibilidade no projeto é essencial para se atingir o sucesso do projeto. Portanto,
esta questão deve ser levada para todos os membros do projeto e seus resultados
avaliados. Frente a estes resultados devem ser definidas as ações necessárias.
 A Universidade de Mogi das Cruzes deve identificar o significado individual desta
implementação a cada um de seus colaboradores. É fundamento buscar, na ótica de
cada membro, o seu papel, os impactos em sua carreira, responsabilidades, suas
perspectivas e sua segurança na organização. Esta visão deve ser tabulada e
identificada de forma positiva ou negativa para o projeto, buscando assim,
consequentes ações para eliminação ou minimização dos riscos.
 As ferramentas de Análise de Risco devem ser utilizadas durante todo o projeto,
sendo a primeira utilizada no início da fase de planejamento, com o intuito de medir o
nível de suporte existente ao projeto.
 É fundamental que o time acredite no projeto, pois, caso contrário, não há como
garantir o seu sucesso;
8.1. Processo para identificar os riscos:
A identificação dos riscos envolve determinar quais os riscos podem afetar o projeto e
documentar suas características. A principal forma de identificação de riscos para o
projeto serão as reuniões de acompanhamento. A partir destas reuniões novos riscos
podem surgir e passarão a ser acompanhados pelo Gestor de Projetos MIT e pelo Gestor
de Projeto da Universidade de Mogi das Cruzes durante a execução deste.
Para a identificação de riscos:

44
MIT030 – PLANO DO
PROJETO
 Obtenha, junto aos envolvidos, os obstáculos do projeto, quer sejam estes
preocupações, dificuldades no projeto, impedimentos, deficiência observadas,
dificuldades no andamento dos trabalhos, etc.;
 Identifique, desde seu ponto de vista, como podemos minimizar ou eliminar estes
obstáculos;
 Identifique também como o projeto pode ser melhorado e encurtado;
 Analise a origem dos obstáculos e relacione-os a problemas relacionados à Educação
e Treinamento, Reporte hierárquico, desconhecimento da Metodologia, etc.;
 Procure verificar, com cada usuário, quais serão os benefícios ganhos ao se resolver
este obstáculo;
 Analise as informações históricas, listas de riscos já conhecidos, materiais de outros
projetos da organização, cultura da empresa, exigências legais, etc.;
 Determine um responsável para cada risco identificado;
 Registre os riscos na planilha de riscos disponibilizada pela MIT (MIT036).
8.2. Processo para qualificar e priorizar os riscos identificados:

A Matriz de Riscos permite a identificação das fontes de riscos e a qualificação dos
mesmos quanto às categorias correspondentes. Nesta matriz, os riscos serão
relacionados e categorizados, especificando a probabilidade de ocorrência e o impacto
dos mesmos no projeto. O fator de risco permitirá a definição da estratégia mais
adequada, determinando os responsáveis e as ações a serem tomadas para o tratamento
do risco.
Classificação por categorias.

Existem várias formas para efetivar esta classificação, podendo ser considerados os
riscos individuais ou os riscos pessoais relacionados aos participantes do projeto, riscos
de credibilidade do projeto, riscos técnicos relacionados às ferramentas, etc.
Prazo: atrasos nas datas de entrega do projeto e na execução das atividades.
Escopo: aumento no escopo, escopo indefinido, não cumprimento do escopo definido,
ausência no gerenciamento de mudanças.
Custo: aumento do custo em virtude de problemas com estimativas ou improdutividade
da equipe, aumento de escopo, trabalho adicional.
Qualidade: como principais fatores de risco para esta classe estão os problemas
relacionados a erros de definição e construção. Ainda como risco em qualidade, temos o
não seguimento da metodologia durante os desenvolvimentos, o que poderá acarretar
problemas e retrabalhos no momento das inspeções e auditorias da qualidade.
Gerenciamento de projeto: distribuição ruim de tempo e de recursos, qualidade
inadequada do plano de projeto, mau uso ou falta de conhecimento das disciplinas de
gerência do projeto
8.3. Processo para quantificar o impacto dos riscos nos objetivos do

projeto:
A análise qualitativa de riscos é o processo de avaliação do impacto e probabilidade de
riscos identificados. Este processo prioriza riscos de acordo com os seus efeitos
potenciais nos objetivos do projeto. Cada um dos riscos que forem encontrados para o
projeto deverá ser listado na planilha de riscos para o projeto e classificado de acordo
com as seguintes características:
Probabilidade: chance de o risco acontecer durante a execução do projeto. A

probabilidade é calculada da seguinte forma:

44
MIT030 – PLANO DO
PROJETO
De 0,1 a 0,3: probabilidade baixa ou inexistente;
De 0,4 a 0,6: probabilidade moderada;
De 0,7 a 0,9: probabilidade alta.
Impacto: de acordo com a classe do risco, o quanto irá impactar no projeto caso o risco
aconteça realmente.
De 0,1 a 0,3: impacto baixo ou inexistente.
De 0,4 a 0,6: impacto moderado.
De 0,7 a 0,9: impacto alto.
A partir destas notas atribuídas chega-se ao fator do risco multiplicando a probabilidade
pelo impacto. Este fator então será dado por uma nota entre 0,01 e 0,81. Os riscos serão
então classificados de acordo com a tabela abaixo:
Probabilidade
0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9
Impacto
0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0
0,1
1 2 3 4 5 6 7 8 9 Criticidad
0,0 0,0 0,0 0,0 0,1 0,1 0,1 0,1 0,1 e Baixa
0,2
2 4 6 8 0 2 4 6 8
0,0 0,0 0,0 0,1 0,1 0,1 0,2 0,2 0,2
0,3
3 6 9 2 5 8 1 4 7
0,0 0,0 0,1 0,1 0,2 0,2 0,2 0,3 0,3
0,4
4 8 2 6 0 4 8 2 6 Criticidad
0,0 0,1 0,1 0,2 0,2 0,3 0,3 0,4 0,4 e Média
0,5
5 0 5 0 5 0 5 0 5
0,0 0,1 0,1 0,2 0,3 0,3 0,4 0,4 0,5
0,6
6 2 8 4 0 6 2 8 4
0,0 0,1 0,2 0,2 0,3 0,4 0,4 0,5 0,6
0,7
7 4 1 8 5 2 9 6 3 Criticidad
0,0 0,1 0,2 0,3 0,4 0,4 0,5 0,6 0,7 e Alta
0,8
8 6 4 2 0 8 6 4 2
0,0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8
0,9
9 8 7 6 5 4 3 2 1
Importante:
A análise qualitativa de riscos requer dados precisos e sem influências, envolvendo a
checagem de:
 Entendimento amplo do risco;
 Dados disponíveis sobre o risco;
 Qualidade dos dados;
 Confiabilidade e integridade dos dados
O uso de dados de baixa precisão (Exemplo: se um risco não é bem compreendido) pode
levar a análise qualitativa de pouco uso para o gerente de projeto.

44
MIT030 – PLANO DO
PROJETO
8.4. Reservas para os riscos identificados:
Não há reserva de horas para gerenciamento dos riscos identificados neste projeto. Caso
seja necessário, as horas previstas para o projeto serão renegociadas, considerando os
riscos concretizados e as mudanças ocasionadas pelos mesmos.
8.5. Reservas para riscos não identificados:

Não há reserva de horas para gerenciamento dos riscos não identificados neste projeto.
8.6. Regras para utilização das reservas:

Esta proposta de serviços não apresenta uma margem destinada às ações para
gerenciamento dos riscos, porém mantém-se aberta a possibilidade de renegociação das
condições do projeto caso seja necessário. Quaisquer desvios nos custos previstos serão
justificados e apresentados para que o planejamento do projeto seja atualizado,
formalizando as alterações decorrentes dos riscos que eventualmente se concretizarem.
8.7. Processo para planejar respostas aos riscos identificados:

É o processo de desenvolvimento de opções e determinação das ações para melhorar
oportunidades e reduzir ameaças para os objetivos do projeto.
A partir da classificação dos riscos, os mesmos serão priorizados de acordo com o fator
de risco que estes receberam. Itens mais críticos são os que receberam os fatores mais
altos. Tendo os riscos classificados, os mesmos serão analisados sobre a melhor
estratégia de tratamento para os mesmos. Como estratégias:
Aceitar: a equipe aceita conviver com o risco. Para este caso nenhuma ação é tomada e o
risco é apenas acompanhado. No caso de ocorrência do mesmo, deverá ser elaborado um
plano de ação para solução do problema gerado pelo risco.
Eliminar: ocorre uma mudança no escopo do projeto de modo que o risco seja eliminado.
Neste caso é elaborado no momento do planejamento um plano de ação para possibilitar
a eliminação do risco.
Transferir: transfere-se a responsabilidade do risco para alguém fora da equipe.
Evitar: elaboram-se estratégias de modo a tentar diminuir a probabilidade que o risco
ocorra. Neste caso é elaborado no momento do planejamento um plano de ação para
possibilitar que o risco seja evitado.
Mitigar: tomada de ações que visem reduzir o risco a patamares aceitáveis.
Durante as reuniões com o time de projeto, os riscos devem ser reavaliados de acordo
com a situação atual quanto a probabilidade e o impacto no projeto. Neste caso um novo
fator de risco pode ser atribuído a este. Com base na análise da situação atual, a
estratégia de tratamento do risco pode ser alterada e caso necessário, deverá ser criado
um plano de ação para o tratamento do mesmo.
Os planos de ação na maioria das vezes envolve custos, tempo, recursos, criação de
atividades que requerem mudanças no plano de projeto. Após a análise de riscos os
planos de projeto devem ser atualizados, se necessário.
8.8. Processo para monitorar e controlar os eventos de riscos:

O monitoramento e controle dos riscos é o processo de identificar e assegurar o controle
do risco, monitorando riscos residuais e identificando novos riscos, assegurando a
execução dos planos do risco e avaliando sua eficiência na redução dos riscos.
Dertermina se:
 Respostas ao risco estão sendo implementadas conforme planejado
 Ações de respostas ao risco estão eficazes conforme o esperado ou se novas

respostas devem ser desenvolvidas

44
MIT030 – PLANO DO
PROJETO
 As premissas ainda são válidas
 Analise de tendência da exposição ao risco tem mudado prioridades
 Ocorre um sintoma (gatilho) do risco
 As políticas e procedimentos necessários estão sendo seguidos e adequados para

acompanhar os riscos
 Identificação de novos riscos
Técnicas utilizadas:
 Revisões periódicas dos riscos nas reuniões com a equipe do projeto
Resultados esperados:
 Plano de ação
 Ações corretivas
 Solicitações de mudanças no projeto, se necessário e atualização dos planos
 Atualização de base histórica de projetos base utilização em projetos futuros
8.9. Processo para registro dos riscos:

O processo de conquista dos usuários do projeto deve ser aplicado como elemento base
para mitigar os riscos e motivar os times de trabalho. Para tanto, deve-se elaborar um
programa que atue nas causas e consequências negativas para o projeto e que podem
impedir sua conclusão de acordo com o planejado.
Este processo visa à atuação sobre os indivíduos, para possibilitar-lhes enxergar o projeto
em seus aspectos positivos e trabalharem para mitigar as causas e efeitos negativos.
 A comunicação deve ser ampla e sempre divulgada no tempo mais cedo possível. Os
participantes devem se sentir privilegiado com o recebimento das informações.
Devem ter a percepção que são parte fundamental para o sucesso do projeto e por
isso recebem sempre as comunicações do mesmo no tempo mais cedo possível;
 Os benefícios do projeto devem ser amplamente comunicados, independentemente
de serem pequenos, médios ou grandes, sua divulgação ajudará no incentivo e na
percepção de que o projeto está apresentando retornos;
 É fundamental deixarmos muito claro a Universidade de Mogi das Cruzes nosso nível
de controle sobre o projeto, pois demonstrando nossa organização, estamos passando
claramente uma mensagem de que temos o domínio daquilo que estamos
implementando e, portanto, há uma melhor percepção da redução dos níveis de
riscos. A metodologia de implementação da TOTVS nos orientará sobremaneira para
garantirmos o padrão e a organização do projeto, portanto, jamais deixe de executar
uma atividade colocada como obrigatória no desenvolvimento do mesmo. É muito
importante associar o sequenciamento e o padrão de nossa metodologia com a
necessária velocidade que será observada pelo Cliente.
 Acompanhe o time de projeto e verifique o nível de envolvimento de cada
participante. Este item pode representar um aumento do nível de riscos
 A implementação de um produto de tecnologia empresarial certamente gera algum
desconforto entre os membros da organização, à medida que mudanças relacionadas
ao seu processo, suas atividades e suas funções serão alteradas em maior ou menor

44
MIT030 – PLANO DO
PROJETO
nível. Como as mudanças geram impacto nas atividades correntes e acaba por
agregar novos conhecimentos nas equipes, consequentemente exigirá níveis maiores
de competência. Sem o devido gerenciamento este quadro pode ser visto
negativamente e em função disto, é necessário que o time do projeto responda
sempre detalhando o planejamento do projeto, seu status, obstáculos encontrados e o
consequente envolvimento de todos os membros do grupo na busca das soluções
alternativas que venham a contribuir com a remoção dos problemas e obstáculos
encontrados.
 Uma vez realizadas as análises de riscos, seus resultados devem ser utilizados para
que sejam gerados os respectivos planos de ação, nos quais devem ser abordadas as
soluções de retomada do projeto, tais como: aumento dos níveis de comunicação,
treinamentos, acréscimo de energia e pessoal envolvido nas etapas em atraso do
projeto etc. É preciso deixar claro para os participantes que se as medidas corretivas
e o plano de ação não forem seguidos, implicará em prejuízos para o projeto,
colocando em risco a qualidade, prazo e custos planejados para o mesmo.
 O gestor de projetos da MIT, bem como o gestor do projeto da Universidade de Mogi
das Cruzes, devem avaliar as necessidades individuais de cada participante crítico do
projeto e tentar conciliar estas necessidades com os interesses e metas do projeto.
 Outro aspecto fundamental é que o corpo de gerenciamento do projeto deve
assegurar todo o suporte necessário ao time do projeto.
8.10. Regras para solicitar mudanças no projeto em função da

identificação de novos riscos:
Anexo: Modelo de fluxo para controle de mudanças de riscos (Risk change control
system):

44
MIT030 – PLANO DO
PROJETO
8.11. Regras para atualizar este plano a partir de mudanças nos riscos:
Quaisquer alterações nos riscos já identificados (variação na probabilidade e impacto dos
riscos) serão apresentadas ao Comitê do Projeto, gerando uma nova versão do plano
contendo as modificações aprovadas.
8.12. Regras para questões de riscos não previstas neste plano:

Quaisquer riscos não previstos neste plano e identificados ao longo do projeto deverão
ser imediatamente comunicados ao Coordenador de Projetos MIT para que o tratamento
adequado seja providenciado. É importante ressaltar que estes riscos também poderão
impactar nas condições do projeto, podendo ocasionar na renegociação das variáveis do
mesmo.

44
MIT030 – PLANO DO
PROJETO
9. Gerenciamento da Integração
9.1. Processo e regras para execução de atividades do projeto

Para que todas as mudanças possam ser implementadas com sucesso, a empresa – além
de um possuir um ambiente propício e ferramentas, técnicas e metodologias de trabalho
que suportem a execução do projeto – precisa conhecer profundamente a forma como
seus processos são executados.
Conhecendo os objetivos do projeto, define-se o que deve ser feito (etapas, atividades,
tarefas), por quem (os envolvidos, suas funções e responsabilidades, interações), quando
(a que tempo e a que a hora, relações de precedência), como (informações ou
documentos de entrada; procedimentos, ferramentas e/ou tecnologias utilizadas no
processamento das informações; informações ou documentos de saída), e onde (em que
local, em que tipo de situação, por quais meios).
As atividades serão executadas de acordo com o planejamento aprovado pela

Universidade de Mogi das Cruzes, seguindo o encadeamento definido no cronograma do
projeto. As agendas serão planejadas conforme a disponibilidade dos recursos TOTVS,
pressupondo a disposição dos recursos do cliente para atendimento à equipe do projeto.
Todas as atividades serão executadas seguindo a Metodologia de Implementação TOTVS

(MIT), gerando documentos específicos para cada fase do projeto. O registro formal
destas atividades nos modelos definidos pela MIT é fundamental ao controle de qualidade
do projeto. As auditorias internas visam o cumprimento das normas estabelecidas,
consolidando a aplicação das melhores práticas em gestão de projetos.
9.2. Processo e regras para monitoramento e controle do trabalho do

projeto:
O objetivo do Monitoramento e Controle do Projeto é oferecer um entendimento do
progresso do projeto, de maneira que as ações corretivas apropriadas possam ser
tomadas quando o desempenho do projeto se desviar significativamente do plano. O
monitoramento e controle do trabalho pressupõe as seguintes tarefas:
 Definir procedimento para elaboração e divulgação de relatório de status;
 Definir procedimento de detecção de riscos e proposição de ações corretivas;
 Comunicar os procedimentos da MIT para formalização das entregas do projeto.
O que é um relatório de status?

É o procedimento em que o coordenador de projetos informa o andamento do projeto ao
Comitê do Projeto (gerando um relatório de acompanhamento do projeto). Define-se
também a frequência com que ele deverá fazer isso. O documento irá apresentar o
progresso físico, além de destacar pontos de atenção, riscos mapeados, tendências do
projeto, atividades pendentes e outros itens relevantes.
O que são ações corretivas?

Quando o status real se desvia significativamente dos resultados esperados para o
projeto, as ações corretivas são tomadas para ajustar as situações detectadas. Estas
ações podem exigir o replanejamento, que pode incluir a revisão do plano original,
estabelecimento de novos acordos ou inclusão de atividades de mitigação de riscos
adicionais dentro do plano atual.

44
MIT030 – PLANO DO
PROJETO
9.3. Processo e regras para controle, integração e aprovação das
mudanças solicitadas:
As bases do projeto serão definidas nos planos aprovados pelo Comitê Executivo. Esses
planos irão detalhar os objetivos, estratégias e escopo. Nenhuma alteração será aceita
sem passar por um processo de mudança formal. Alterações nesses documentos serão
efetuadas de maneira controlada, comunicadas e o resultado das decisões devem ser
tomadas em consenso. Essas mudanças serão divulgadas formalmente para os membros
do projeto.
O gestor de controle de mudanças no projeto serão os Gerentes de Projetos de ambas as

partes. São responsabilidades do Gestor de Controle de Mudanças:
 Administrar o processo de controle de mudança alinhado com este instrumento;

 Receber todos os formulários de solicitação de mudança;
 Atribuir numeração para as solicitações de mudança;
 Manter as solicitações de mudança e o registro de controle das mudanças;
 Controlar a distribuição e o encaminhamento das solicitações de mudança;
 Manter o arquivo das solicitações de mudança e o controle de prioridade da mudança
na pasta de projeto da franquia;
 Assegurar que as mudanças prioritárias, juntamente com os documentos necessários,
sejam enviadas aos principais membros da equipe do projeto.
Processo de Controle da Mudança

Encaminhamento da Solicitação de Mudança no Projeto: Qualquer membro da equipe do
projeto pode gerar uma solicitação de mudança. Para gerar uma solicitação de mudança,
os seguintes passos são necessários:
 Preencher o formulário solicitação de mudança;

 Submeter o formulário ao Gestor de Controle de Mudança;
 Número sequencial de mudança é atribuído;
 O Gestor do Projeto efetua a revisão da solicitação de mudança;
 O gestor de controle da mudança manterá o registro de todas as mudanças
solicitadas utilizando o documento de registro de controle de mudanças;
 As solicitações de mudança aprovadas ou rejeitadas serão arquivadas na pasta de
projeto da franquia.
Revisão do Impacto
O Gestor do Projeto da Universidade de Mogi das Cruzes e o Gestor de Projeto da TOTVS –

MIT Tecnologia avaliarão a solicitação de mudança em termos de impacto:
 Objetivos do negócio;
 Estratégia do projeto;
 Cronograma;
 Custos e a necessidade de contratação para execução desta mudança;
 Escopo;
 Riscos e qualidade do projeto;
 Este impacto será documentado no formulário de solicitação da mudança, juntamente
com os respectivos pareceres e demais possibilidades de problemas.

44
MIT030 – PLANO DO
PROJETO
Aprovação da Solicitação de Mudança
A solicitação de mudança seguirá os seguintes passos para aprovação:
 Mudanças serão analisadas pelo Gestor do Projeto e, se tiverem impacto nos planos,
devem ser autorizadas pelo Comitê Executivo.
 O Gestor do Projeto decidirá se a solicitação de mudança pode esperar até a próxima
reunião do Comitê Executivo para aprovação. Caso não possa, deve solicitar uma
reunião extraordinária, ou poderá buscar autorização individualmente dos membros
do Comitê Executivo.
Prioridades de Mudança
 Para possibilitar a execução das mudanças aprovadas, as solicitações de mudanças

deverão receber um número de prioridade para seu desenvolvimento. Este número
deve ser assinalado nos formulários de controle do Gestor de Controle de Mudança.
 A equipe de projeto poderá iniciar a implementação da mudança seguindo a devida
prioridade, já assinalada pelo Gestor de Controle da Mudança e liberada pelo mesmo.
Revisão dos planos de projeto
 Os documentos do projeto afetados pela prioridade da mudança serão revisados de

acordo com as mudanças aprovadas e reemitidos.
 As observações de revisão dos documentos incluirão detalhes como o número da
solicitação de mudança e demais detalhes da mudança.
Controle da Documentação do Projeto
 Documentos controlados, desenvolvidos durante o ciclo de vida do projeto, são

autorizados pelo Gestor e pelo Coordenador de Projeto TOTVS e são disponibilizados à
equipe do projeto como instrumentos de trabalho.
 Mudanças nesses documentos, após o envio à equipe do projeto, somente serão
efetuadas mediante procedimentos formais do processo de controle de mudança.
 Mudanças de documentos controlados e disponibilizados à equipe, que não afetam os
Planos de Controle do Projeto, podem ser aprovadas pelo Gestor e pelo Coordenador
de Projeto TOTVS sem o consentimento do Comitê Executivo.
9.4. Processo e regras para encerramento do projeto:

A etapa de encerramento do projeto corresponde ao processo que permite a finalização
formal de todas as atividades de um projeto. O Termo de Encerramento será assinado
pelo cliente, formalizando a entrega dos serviços contratados. Isso inclui a finalização de
todas as tarefas correspondentes do projeto, determinando procedimentos necessários
para verificar os documentos referentes às entregas do projeto.
Nessa fase também é elaborado um documento contendo o registro histórico do projeto,

ou seja, um documento descritivo sobre o aprendizado obtido (tanto para pontos
positivos como para lições negativas), que junto com o toda documentação do projeto,

44
MIT030 – PLANO DO
PROJETO
servirá de base de conhecimento para próximos projetos e para melhorias nos serviços
prestados pela TOTVS.
Aprovação:
Aprovador por: Assinatura Data
Ronaldo Vitória ___/___/___
Adilson de Oliveira ___/___/___
Michihiko Tanimoto ___/___/___
Fernanda Ferraz ___/___/___

44

Plano Do Projeto Backoofice Modelo

Enviado por

Direitos autorais:

Formatos disponíveis

Plano Do Projeto Backoofice Modelo

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Plano Do Projeto Backoofice Modelo

Enviado por

Direitos autorais:

Formatos disponíveis

MIT030 – PLANO DO

Nome do projeto: Implantação ERP Totvs – Módulos BackOffice

Responsáveis: Michihiko Tanimoto

Aprovadores: Ronaldo Vitória

MIT030 – Plano do Projeto

MIT030 – Plano do Projeto

8. GERENCIAMENTO DOS RISCOS...................................................................38

MIT030 – Plano do Projeto

O plano de projeto é a declaração de entendimento dos objetivos do projeto e

 O entendimento e alinhamento de expectativas entre a TOTVS (Mit Tecnologia) e a

 A aplicação da metodologia de gerenciamento do projeto acordada neste documento

 Nomear o Gestor do Projeto, o qual terá a função de planejar, monitorar, medir e

 Serão alocados consultores especialistas nos módulos e serviços comprados,

 Monitoramento dos serviços desenvolvidos para garantir a integral aderência às

MIT030 – Plano do Projeto

 Essas mudanças serão divulgadas formalmente para os membros do projeto, para

 Somente o comitê diretivo tem a responsabilidade e autoridade de promover e decidir

2.1. Nome do projeto:

2.2. Patrocinador (Sponsor):

2.3. Gerente do projeto do cliente, autoridade e responsabilidade

2.4. Fatores de sucesso do projeto:

 Prazo compatível com o escopo;

 Equipe de TI envolvida full time;

 Treinamento prévio dos usuários e evitar a substituição dos mesmos ao longo do

 Disponibilidade dos usuários para executarem as atividades de implementação;

 Não ocorrer interrupções na execução do projeto, respeitando o planejamento;

 Tarefas concluídas pelos usuários conforme planejado;

 Promover reuniões periódicas com o comitê;

 Definição de um processo de comunicação claro e objetivo;

 Envolvimento do patrocinador, promovendo a mudança de cultura na empresa;

 Disponibilizar a infraestrutura necessária ao projeto (sala, máquinas, rede, telefone,

MIT030 – Plano do Projeto

2.5. Macro Escopo:

Segue o EAP em Anexo I para melhor visualização.

 Especificação de sistemas e/ou funcionalidades que não façam parte da

MIT030 – Plano do Projeto

 Desenvolvimento de programas específicos de interface entre os produtos TOTVS com

 Desenvolvimento de programas específicos para a importação da carga de dados,

 Execução e desenvolvimento de programas para extração de dados das bases de

 Fornecimento de softwares ou hardwares básicos ao desenvolvimento do projeto

 Fornecimento de softwares de segurança ou para sistemas operacionais;

 Configuração de rede ou instalação de softwares básicos;

 Configuração de links de acesso remoto entre pontos distintos;

 Serviços de administração de banco de dados;

 Rotinas de backup de servidores ou bancos de dados;

 Treinamento para usuários finais e de implementação de quaisquer módulos e

 Inserção de dados nas bases dos produtos TOTVS, manual ou eletronicamente. A

 Instalação de produtos em outras unidades e locais da Universidade de Mogi das

 Reuniões extraordinárias, exceto as de pontos de controle, previstas no projeto;

 Horas gastas em apresentação do trabalho efetuado ou a efetuar para os diversos

 Retrabalhos causados por falta de definição ou capacidade do usuário designado pela

MIT030 – Plano do Projeto

 Retrabalhos provocados por problemas nas atividades de responsabilidade dos

 Horas em que o consultor da TOTVS - Mit Tecnologia ficou acompanhando a execução

 Este projeto de implementação não contempla serviços de consultoria de processos,

 Qualquer item não explicitamente descrito neste documento.

Serão consideradas horas improdutivas para o bom desenvolvimento dos Trabalhos,

 Falta de recursos de responsabilidade da Universidade de Mogi das Cruzes para

 Horas de locomoção para a realização de trabalhos em outras unidades da