Embed Size (px)
Citation preview
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
FACULDADE INTEGRADA AVM
SISTEMA DE ATENDIMENTO DE PACIENTES
Por: Reginaldo Jorge Nunes de Figueredo
Orientador
Prof. Nelsom Magalhães
Rio de Janeiro
2011
2
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
FACULDADE INTEGRADA AVM
SISTEMA DE ATENDIMENTO DE PACIENTES
Apresentação de monografia à Universidade
Candido Mendes como requisito parcial para
obtenção do grau de especialista em Gestão de
Projetos.
Por: Reginaldo Jorge Nunes de Figueredo
3
AGRADECIMENTOS
Agradeço a Deus, aos meus amigos da
área médica e ao corpo docente que
me orientou para conclusão desta
pesquisa.
4
DEDICATÓRIA
Dedico esta pesquisa ao meu Pai que
sempre acreditou em meu potencial.
5
RESUMO
Os fatores de sucesso para a criação de qualquer projeto inicialmente
está em entender a necessidade do cliente ou do mercado no foco que se
pretenda atingir ou alcançar, para elaborar um escopo detalhado e
mensurável, que permita o entendimento dos benefícios no âmbito social,
financeiro e que agregue satisfação à sociedade.
Este projeto tem como objetivo criar um sistema de saúde web para
integrar o histórico e o acompanhamento do paciente (associado e particular)
desde o agendamento, consultas, exames alta médica, faturamento de
consultas e dos planos de saúde associados.
Estaremos percorrendo todo o ciclo de vida do projeto e colocando em
prática algumas áreas de conhecimento descritas pelo PMBOK.
6
METODOLOGIA
Esta pesquisa foi desenvolvida pelo método de investigação, em
consultórios médicos que possuem convênios com a rede credenciada de
planos de saúde, na cidade do Rio de Janeiro.
Terá como base as orientações da metodologia de gerenciamento de
projetos descritas PMI. Um guia de conhecimentos em gerenciamentos.Guia
PMBOK®-EUA Project Management Institut, Edição 2008. e alguns livros como
o de VARGAS, Ricardo V. Manual Prático do Plano de Projeto. 4ª Ed. RJ,
Brasport, 2009.
7
SUMÁRIO
INTRODUÇÃO 08
CAPÍTULO I- A Investigação do Projeto 10
CAPÍTULO II - Plano de Gerenciamento de Escopo 12
CAPÍTULO III- Mudanças e o Ciclo de Vida do Projeto 17
CAPÍTULO IV- Ciclo de Vida do Produto 19
CAPÍTULO V- Plano de Gerenciamento de Requisitos 21
CAPÍTULO VI - Plano de Gerenciamento de Risco 25
CAPÍTULO VII- Plano de Lições Aprendidas 32
CONCLUSÃO 39
ANEXOS 41
BIBLIOGRAFIA CONSULTADA 48
ÍNDICE 49
ÍNDICE DE FIGURAS 52
FOLHA DE AVALIAÇÃO 53
8
INTRODUÇÃO
O avanço da tecnologia contribuiu e muito para o sucesso e otimização
dos processos nas organizações.
De igual forma a tecnologia vem contribuindo no processo integrado
das informações empresariais, porém ainda precisa atingir a área de saúde
para qualificar a informação e seus processos.
Apesar de redes hospitalares possuírem um programa de cadastro
com a informação do paciente, ainda existem limitações por não ser integrado,
limitando os benefícios e a qualidade do sistema de saúde.
Exemplificando a questão mencionada podemos citar a velocidade no
atendimento aos pacientes. Normalmente as salas de espera ficam cheias e o
atendente precisa repassar para o médico o histórico de patologia do paciente,
que se encontra na maioria das vezes em um arquivo manual, com fichas de
papéis que se degradam com o passar do tempo.
Este sistema tende a qualificar a saúde em seus processos de
trabalho, por ser totalmente integrado e minimizar esforços de diversos setores
e áreas relacionadas.
Digamos que um paciente ao chegar a um hospital seja recepcionado
e seus dados cadastrais sejam armazenados em um programa web de
informação, este mesmo paciente ao chegar ao consultório será atendido por
um médico que já está com suas informações em tela e irá registrar no mesmo
sistema as informações de saúde do paciente.
9
Em caso de exames a serem realizados, o estabelecimento
credenciado junto ao plano de saúde, recebe a informação do exame
totalmente informatizado, eliminando alguns problemas como: o
estabelecimento não conseguir decifrar a letra do médico e a não realização
integral de todos os exames solicitados. Este fato já ocorreu pessoalmente
comigo e foi necessário o retorno ao consultório e nova solicitação do pedido
com letra legível, houve perda de tempo, frustração e devido o mundo robótico
que vivemos a dificuldade de retornar e aguardar novamente em filas de
espera.
A intenção não é acabar com as salas de espera, mas qualificar a
informação em todos os seus segmentos seja ele de custo, pois o faturamento
estará integrado, redes associadas, histórico dos pacientes, remédios
prescritos, histórico de medicamentos e laboratórios conveniados e acima de
tudo uma qualidade de vida tanto para o médico como para as áreas
integradas por minimizar desgastes pela amplitude do sistema.
Para que este projeto seja competente suficiente é necessário
estabelecer critérios e premissas de gerenciamento de projeto.
É importante que todas as áreas de conhecimento estejam presentes
na criação do Sistema de Saúde Web para sua eficácia.
O PMBOK será o carro diretor para a busca deste sucesso, pois nele
contemplamos uma metodologia de gerenciamento de projetos que abrange o
ciclo de vida do produto e do projeto e as áreas de conhecimento que
necessitamos observar para obtermos a qualidade desejada ao oferecer um
produto junto ao cliente, que neste caso em específico é a área de saúde.
10
CAPÍTULO I
A INVESTIGAÇÃO DO PROJETO
Para levantar o escopo deste projeto foi necessário entrar em contato
com alguns consultórios médicos, como o da Dra. Lilian Camargo, na Rua
Uruguaiana, 39 no Centro do Rio de Janeiro, com o do Dr. Rogério Mangi na
Rua Sete de Setembro no Centro do Rio de Janeiro, com atendentes de
laboratórios e com o público que utiliza a área de saúde para atendimento.
A necessidade de inovar o programa de atendimento e controle de
pacientes é um desejo dos médicos e também dos pacientes.
O escopo é amplo e por este motivo será dividido em ondas para ser
gerado e aprimorado conforme evolução e aplicação junto à rede médica.
Para o desenvolvimento do piloto foi escolhido o consultório da Dra.
Monica Chatack e Arnaldo Chatack que são ginecologistas que trabalham na
Rua Conde de Bonfim, na Tijuca.
O critério de escolha para o piloto foi o conhecimento existente entre
os citados e a empresa que atuo como prestador de serviços na área de
informática, no seguimento de manutenção, rede e desenvolvimento
tecnológico e apoio de representantes de laboratórios que compartilham
experiências no consultório dos Chatack.
Na primeira onda teremos o levantamento de requisitos do sistema, ou
seja, conhecer a área de negócio, junto às áreas interessadas (área médica,
área dos propagandistas e área dos planos de saúde). A primeira onda irá
atender o controle de gestão do paciente.
11
Para desenvolver este projeto será necessário elaborar um minimundo
com as informações coletadas durante o levantamento de requisitos do
sistema, com a finalidade de confirmar o objetivo do mesmo.
Deverão ser elaborados os diagramas de caso de uso que mostram
quais os atores e processos do sistema. Criados os diagramas de classes que
identificam as identidades, os atributos e seus métodos, elaborados os
modelos de entidade de relacionamento obedecendo às técnicas de
modelagem orientada a objeto. Deverá se feita a escolha da linguagem da
programação a ser utilizada. A implementação do sistema na linguagem
escolhida. Ser feita a elaboração do plano de teste junto ao cliente e a
implantação do módulo da primeira onda que será acompanhada junto ao
cliente.
Teremos que ter alguns cuidados, tais como: disponibilizar uma
qualificada equipe de suporte. Estaremos trabalhando mais a frente à
necessidade da equipe e dos envolvimentos dentro da estrutura da empresa
que citei acima como prestador.
As próximas ondas irão seguir o mesmo ciclo citado acima, tendo
como objetivo na segunda onda: Fazer a integração do programa com os
sistemas dos representantes dos laboratórios e a terceira onda irá integrar o
programa com os sistemas dos planos de saúde.
A seguir, nos próximos capítulos, iremos trabalhar com alguns planos,
tais como: plano do escopo, plano de requisitos, plano de risco e lições
aprendidas. Sabemos que os demais planos são necessários em projetos para
serem bem sucedidos, mas trataremos apenas dos planos já citados com o
objetivo de darmos andamento no escopo mapeado e entendermos como
serão levantados os requisitos do projeto. Entenderemos ainda sobre o ciclo
de vida do projeto em seu processo de mudança e do ciclo de vida do produto
do projeto.
12
CAPÍTULO II
PLANO DE GERENCIAMENTO DO ESCOPO
2.1- Objetivo
O plano de gerenciamento de escopo tem o objetivo de orientar como a
equipe do projeto: Sistema de Atendimento de Pacientes irá documentar
verificar e controlar o escopo do projeto.
2.2- Descrição dos processos
O gerenciamento de escopo do projeto inclui os processos necessários
para garantir que o mesmo inclua todo e somente o trabalho necessário, para
a conclusão do projeto, tratando a definição e controle do que está e do que
não está incluído no projeto que compõe o projeto: Sistema de Atendimento de
Pacientes.
É importante ressaltar que o projeto: Sistema de Atendimento de
Pacientes está dividido em ondas e terá as seguintes fases: iniciação,
planejamento, execução, monitoramento e controle e encerramento.
2.3- Planejamento do escopo
Serão necessárias algumas frentes de trabalho para o desenvolvimento
deste projeto que atenderá uma rede credenciada da área de saúde, sendo
estas: Frente Funcional; Frente Tecnologia, Frente Gestão da Mudança e
Frente Gestão de Projetos.
13
O planejamento do escopo durante as fases de iniciação e
planejamento, da primeira onda, será feito através de reuniões para
esclarecimento de requisitos e para entendimento de especificidades do
projeto.
O planejamento do escopo nas demais ondas e suas respectivas fases
irá considerar o mesmo processo: reuniões de alinhamento para
esclarecimentos ou dirimir dúvidas sobre requisitos, estudos dos processos e
revisão dos requisitos a serem alinhados.
2.4- Definição do escopo
A declaração de escopo da fase de execução será composta da
descrição dos objetivos da fase, as premissas, restrições e, com base nela,
serão feitas as especificações detalhadas dos componentes do escopo do
projeto e suas respectivas entregas.
A consolidação do escopo do projeto será finalizada ao término das
atividades de: análise de requisitos, levantamento de GAP´s, levantamento e
revisão de interfaces.
2.5- Criação da estrutura analítica do projeto – EAP
A primeira versão da EAP para atender as etapas de iniciação e
planejamento da primeira onda será estruturada a partir do escopo do produto
e do projeto de forma preliminar.
A revisão da EAP para as demais fases do projeto terá como objetivo
assegurar que seja identificado como cada atividade adicional irá contribuir
para geração do produto ou subproduto.
14
A EAP deve ser detalhada até o nível de atividades em que o líder
responsável pela frente de trabalho possa gerenciar seus entregáveis.
Para o projeto, serão consideradas as seguintes orientações para
estruturação dos pacotes de trabalho em atividades (entregáveis): São reais e
podem ser estimados de forma confiável, podem ser completados nos padrões
de 4 a 40hs (0,5 a 5 dias) ou 8 a 80hs (1 a 10 dias), as tarefas com duração
maior ou igual a cinco dias deverão ter métricas associadas, possuem um
resultado significativo, podem ser completados sem necessidade de mais
informações, poderão ser divididos posteriormente, pelo time de projeto, em
tarefas menores.
Para fase de execução, reuniões serão programadas com os líderes das
frentes de trabalho para alinhamento e validação dos pacotes de trabalho, com
objetivo de refletir o escopo do projeto e todo trabalho para sua realização.
O PMO apoiará os líderes das frentes de trabalho para atender às
seguintes premissas: Fornecer uma visão gráfica do escopo do projeto,
prevenir o esquecimento e a falta de entendimento sobre as atividades, facilitar
a comunicação entre todos os “stakeholders” (interessados), fornecer ao time
uma visão do todo e fornecer uma base segura para estimativas de tempo e
recursos.
Figura 1 – Diagrama de Integração (Dinsmore, 2010 - Universidade
Corporativa, Módulo 04, pág. 16).
15
2.6- Linha de base do escopo
A declaração do escopo detalhada que deverá ser aprovada e o
dicionário da EAP associados a ela constituem a linha de base do escopo do
projeto.
2.7- Verificação do escopo
A verificação do escopo é o processo de obtenção da aceitação formal
pelas partes interessadas do escopo do projeto concluído e dos entregáveis
associados.
A verificação do escopo do projeto incluirá a revisão das entregas para
garantir que cada uma delas serão concluídas de forma satisfatória. Se o
projeto for finalizado antes do término (abortado), o processo de verificação do
escopo do projeto deve determinar e documentar o nível e a extensão do
trabalho realizado.
A verificação do escopo difere do controle da qualidade porque a
verificação do primeiro trata principalmente da aceitação das entregas,
enquanto o segundo trata principalmente do atendimento aos requisitos de
qualidade especificados para as entregas.
A ferramenta que será utilizada para a verificação do escopo será a
inspeção, através de atividades de medição, exame documental e testes
incumbidos de determinar se os resultados estão de acordo com os requisitos
do projeto.
2.8- Controle do escopo
O escopo do projeto será controlado durante as fases do projeto através
da comparação e análise em relação à linha de base.
16
O controle do escopo terá o foco nos GAP’s identificados na fase de
planejamento.
2.9- Matriz de rastreabilidade de requisitos
Tem por objetivo controlar o escopo do projeto através do entendimento
dos requisitos, do desdobramento em requisitos específicos e do
relacionamento desses com os demais documentos da metodologia de
implantação do projeto.
A Matriz também identificará em que onda os requisitos foram
atendidos, a forma como foram atendidos (por completo ou parcial) com
justificativas, os requisitos a serem negociados devido á decisão de
implementação de forma diferente da inicialmente prevista.
Dessa forma, ao término do projeto, pode-se assegurar que a solução
implantada atenderá às expectativas e necessidades do cliente refletidas nos
requisitos.
17
CAPÍTULO III
MUDANÇAS E O CICLO DE VIDA DO PROJETO
No ciclo de vida do projeto toda e qualquer alteração no escopo do
projeto, sejam elas em requisitos, GAP’s, interfaces e premissas, deve ser
apresentada formalmente através do documento de solicitação de mudança.
As solicitações de mudanças podem acontecer durante todo o ciclo de
vida do projeto. Porém, para garantir que essas solicitações sejam revisadas
por todas as partes envolvidas, tenham seu impacto coerentemente mapeado
e sua aprovação baseada em dados e informações concretas.
3.1- Quando deve ser acionado.
Sempre que surgir qualquer tipo de solicitação de alteração em relação
à linha de base de escopo e cronograma, feita por qualquer interessado, que
impacte a qualidade e/ou recursos do projeto, como por exemplo: solicitações
de melhoria, mudança de requisitos etc., assim como solicitações oriundas das
informações periódicas de status do projeto.
3.2- Quem participa. A equipe do projeto está envolvida em todas as solicitações de
mudanças;
O Comitê Gestor que será constituído pelos líderes das frentes de
trabalho, irá avaliar os impactos e deliberar sobre os GAP’s encaminhados pela
equipe do projeto que será acionado sempre que houver decisões e mudanças
operacionais para o projeto, o Comitê Executivo do Projeto que será
18
constituído pelo cliente, o gerente de projeto e outras partes interessadas
importantes para o progresso decisório das atividades do projeto, será
acionado sempre que houver decisões e mudanças estratégicas para o
projeto.
A solicitação de mudança se destina apenas à documentação interna do
projeto, sendo necessário periodicamente agrupar todas as solicitações em um
documento de informação padronizada para obter a deliberação junto ao
cliente e assim formalizar tais decisões.
No planejamento, momento e, que a solução é detalhada, normalmente
surge um número maior de solicitações de mudança no escopo de cada onda.
A partir desta fase, as requisições são mais pontuais e devem ser
controladas para não prejudicar tanto a fase de execução quanto a fase de
encerramento.
19
CAPÍTULO IV
CICLO DE VIDA DO PRODUTO
Durante a fase de realização serão configuradas as soluções
identificadas durante a fase de planejamento e desenvolvidas as soluções para
atendimento dos requisitos a serem coletados.
É de suma importância manter o controle do que está sendo
desenvolvido, garantir o melhor processo de elaboração e aprovação das
especificações funcionais e técnicas para minimizar impactos de solicitações
de mudança e problemas de homologação na ocasião dos testes.
Assim sendo faz-se necessário um processo de controle de mudanças e
gerenciamento da configuração para garantir o escopo das especificações e
uma absorção controlada das mudanças necessárias, a fim de manter a
estabilidade da execução do projeto. Para tal é preciso mapear todas as
etapas da configuração e desenvolvimento a serem desenvolvidos, definir o
ciclo de vida do produto, para controlar as mudanças realizadas e manter a
integridade e rastreabilidade do que está sendo realizado.
4.1- Etapas do trabalho:
Definir as configurações, GAP’s e interfaces que serão desenvolvidos,
construir as especificações funcionais e técnicas e elaborar a gerência da
configuração (controle de versão, controle de mudanças e integração contínua,
ou seja, manutenção da integridade da linha de base, envio de status para
todos os envolvidos).
20
A gerência da configuração e o gerenciamento do próprio plano de
gerenciamento do escopo são importantes nesta etapa.
A gerência da configuração identifica, armazena e gerencia todos os
itens de configuração durante todo o ciclo de vida do produto, garante o
histórico de todas as alterações efetuadas, proporciona a recuperação de
determinada configuração quando isso for necessário.
O controle de versão é composto de duas partes: o repositório e a área
de trabalho. O repositório armazena todo o histórico de evolução do projeto,
registrando toda e qualquer alteração feita em cada item versionado.
Na etapa do gerenciamento do plano de gerenciamento do escopo, o
mesmo ficará sob a responsabilidade do PMO, porém o gestor do projeto
deverá ser informado e deliberar a análise feita pelo PMO sobre mudanças
solicitadas. O Gestor do Projeto deverá estar ciente e aprovar qualquer tipo de
decisão.
21
CAPÍTULO V
PLANO DE GERENCIAMENTO DE REQUISITOS
5.1- Objetivo Este plano tem por objetivo documentar e orientar como os requisitos do
projeto: Sistema de Atendimento de Pacientes serão analisados, entendidos,
desdobrados e gerenciados até a sua entrega.
5.2- Descrição dos processos A gestão de requisitos tem como foco estabelecer um entendimento
comum entre o cliente ou usuário e a equipe contratada para atender ao
escopo definido. Conceitualmente requisitos são inevitavelmente incompletos e
inconsistentes. Requisitos frutos do desdobramento surgem durante o estudo
detalhado e entendimento da solução. Faz-se necessário um controle de
mudanças estruturado para não impactar a implementação da ferramenta e
garantir que os requisitos originais, revisados na fase de desenho da solução
serão atendidos. Os seguintes processos devem estar definidos: planejamento
do plano de gerenciamento de requisitos, identificação e definição macro dos
requisitos, detalhamento dos requisitos, garantia da rastreabilidade,
monitoramento e controle e controle de mudanças.
5.3- Planejamento do plano de gerenciamento de requisitos O plano de gerenciamento dos requisitos documenta como os mesmos
serão analisados, documentados e gerenciados do início ao fim do projeto.
Requisitos são funções que esperamos que um sistema seja capaz de
desempenhar e o nível de desempenho que desejamos dessas funções. São
utilizados para definir necessidades tanto de negócio quanto de sistemas e
22
ainda são condição ou capacidade necessária para o usuário resolver um
problema ou atingir um objetivo.
Requisitos não são exatamente especificações referentes a como uma
dada função será implementada. Esse tipo de detalhamento faz parte do
desenho de especificações.
A coleta dos requisitos é o processo de definição e documentação das
necessidades quantificadas e documentadas dos processos, dos usuários
finais, dos patrocinadores e demais partes interessadas para alcançar os
objetivos do projeto. O sucesso do projeto é diretamente influenciado pela
atenção na captura e gerenciamento dos requisitos do projeto e do produto. Os
requisitos precisam ser obtidos, analisados e registrados com detalhes
suficientes para serem medidos uma vez que a execução do projeto se inicie.
A documentação descreve como os requisitos individuais atendem às
necessidades de negócio. Eles podem começar em um alto nível e,
progressivamente, se tornarem mais detalhados conforme o entendimento é
melhorado. Antes das linhas de base serem estabelecidas, os requisitos
devem ser não ambíguos, mensuráveis, passíveis de testes, investigáveis,
completos, consistentes e aceitáveis para as principais partes interessadas.
Dentre os componentes do plano de gerenciamento de requisitos estão:
de que forma as atividades dos requisitos serão planejadas, rastreadas e
relatadas, as atividades de gerenciamento da configuração, tais como: de que
modo as mudanças dos requisitos serão iniciadas, como os impactos serão
analisados, como serão rastreados, monitorados e relatados, os níveis de
autorização necessários para aprovar tais mudanças, o processo de
priorização dos requisitos, as métricas do produto que serão usadas e os
argumentos que justificam usá-las, a estrutura de rastreabilidade, ou seja, que
atributos dos requisitos serão captados na matriz de rastreabilidade e a que
outros documentos de requisitos do projeto estarão ligados.
23
5.4- Garantia da rastreabilidade A planilha de controle e rastreabilidade de requisitos têm o objetivo de
ligar os requisitos às suas origens e permitir o rastreamento desses ao longo
de todo o ciclo de vida do projeto. Além disso, deve: fornecer insumos para o
gerenciamento das mudanças de escopo do produto, garantir a qualidade do
projeto através do entendimento dos requisitos gerais, do desdobramento em
requisitos específicos e do relacionamento desses com os demais documentos
da metodologia de implantação do projeto.
Dessa forma, ao término do projeto, pode-se assegurar que a solução
implantada atenderá às expectativas e necessidades levantadas por meio dos
requisitos.
5.5- Monitoramento e controle Para monitorar e controlar se os requisitos técnicos e funcionais foram
atendidos, ao final da fase de execução deverá ser feita uma verificação de
item a item. A matriz de rastreabilidade de requisitos é a ferramenta para a
verificação dos requisitos funcionais.
Para os requisitos técnicos será utilizado um check-list com a relação
dos requisitos que devem ser coletados inicialmente. Ambas as verificações
devem ter o aceite formal pela área responsável no cliente
5.6- Controle de mudanças As solicitações de mudanças têm como principal objetivo a visualização
e controle do que está sendo alterado durante o projeto. Ajuda na execução e
gestão do que está sendo implementado, evitando a execução de atividades
ou alterações no escopo que não estavam previstos no planejamento.
24
Toda e qualquer alteração nos requisitos deve ser apresentada
formalmente através do documento de solicitação de mudança.
Indefinições de escopo na fase de planejamento e desenho da solução
podem impactar a construção da solução e o consequente atendimento de
requisitos. Além disso, restrições de data e recursos aumentam os riscos de
alteração de escopo.
As solicitações de mudança podem acontecer durante todo o ciclo de
vida do projeto. Porém é preciso garantir que essas solicitações sejam
revisadas por todas as partes envolvidas e mapeados seus impactos.
25
CAPÍTULO VI
PLANO DE GERENCIAMENTO DE RISCOS
6.1- Objetivo O gerenciamento de riscos do projeto inclui os processos que tratam de
identificação, análise, respostas, monitoramento e controle e planejamento do
gerenciamento de riscos em um projeto. A maioria desses processos é
atualizada durante todo o projeto.
Os objetivos do gerenciamento de riscos do projeto são aumentar a
probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o
impacto dos eventos adversos ao projeto.
A gestão de Riscos no PMI é composta dos seguintes processos:
planejamento de gerenciamento de riscos, identificação dos riscos, análise
qualitativa dos riscos, análise quantitativa dos riscos, planejamento de
respostas aos riscos e monitoramento dos riscos.
6.2- Planejamento de gerenciamento dos riscos O objetivo do planejamento de gerenciamento dos riscos é decidir como
abordar, planejar e executar as atividades de gerenciamento de riscos de um
projeto.
Para planejar como serão tratados os riscos em um projeto é preciso
considerar fatores externos e internos importantes, que conceitualmente são
as entradas para o processo, a saber: fatores externos, fatores ambientais da
empresa e ativos e processos organizacionais.
26
O processo de gerenciar riscos possui uma metodologia própria em que
são abordadas algumas análises, tais como: qualitativa e quantitativa, para que
haja condições de compreender a probabilidade e o impacto do risco e
analisar qual a melhor tratativa a ser dada.
6.3- Análise qualitativa dos riscos Corresponde à valoração qualitativa incorporada aos riscos, através dos
documentos de registro, de forma a viabilizar critérios de análise para a sua
priorização. Os principais parâmetros considerados para a qualificação do risco
são: probabilidade que mede a chance de ocorrência risco, impacto que mede
o alcance que as consequências do risco podem ter para o projeto, exposição
que é calculado como função dos parâmetros anteriores e mede o quão
próximo o risco está de se tornar um problema ou um potencial benefício, em
conjunto com a intensidade e suas consequências para o projeto.
Todo parâmetro registrado deverá ser analisado e classificado de
acordo com os valores quantitativos pré-definidos para os mesmos, juntamente
com seus racionais qualitativos. A atividade de análise qualitativa de riscos
está embutida nas atividades de dois até quatro do processo geral
apresentado no Planejamento do Gerenciamento de Riscos.
Figura 2 – Diagrama de Riscos (Dinsmore, 2010 – Universidade
Corporativa – Módulo 11 pág. 09).
27
6.4- Análise quantitativa dos riscos O processo análise quantitativa de riscos atua sobre os riscos
identificados, de forma a analisar seus parâmetros através de uma
classificação numérica.
A análise quantitativa corresponde à valoração quantitativa incorporada
aos riscos, através dos parâmetros de probabilidade, impacto e exposição
apresentados no processo análise qualitativa de riscos, provendo suporte para
a sua análise e priorização. Conforme observado no processo análise
qualitativa de riscos, a análise quantitativa e qualitativa devem ser abordadas
de forma conjunta, visto que as informações qualitativas se constituem no
racional descritivo dos valores relacionados aos parâmetros. Portanto, a
análise qualitativa de riscos está embutida nas atividades de dois até quatro do
processo geral apresentado no planejamento do gerenciamento de riscos;
Detalharemos a seguir os parâmetros citados e suas valorações pré-
definidas, bem como outros parâmetros pertencentes aos documentos de
registro de riscos, conforme a figura abaixo:
Figura 3 - Diagrama de Registro Riscos (Dinsmore, 2010 -
Universidade Corporativa – Módulo 11, pág. 9).
6.5- Natureza e categoria dos riscos A classificação quanto a natureza e categoria é o ponto de partida para
o entendimento dos riscos e identificação da melhor estratégia de ação
possível.
28
6.6- Probabilidade e impacto dos riscos
Refere-se à probabilidade da evolução de um risco para um problema.
Deve ser definida utilizando-se a abordagem listada a seguir:
Figura 4 – Metodologia de Riscos (Dinsmore, 2010 - Universidade
Corporativa, Módulo 11, pág. 12).
O impacto indica o próprio impacto potencial desse risco, caso se
transforme em um problema real, em termos de perturbação nos objetivos,
produtos, benefícios e agenda do Projeto.
Figura 5 – Metodologia de Riscos (Dinsmore, 2010 – Universidade
Corporativa, Módulo 11 pág. 12).
A matriz de exposição (probabilidade x impacto) é o grau de exposição
atribuído a determinado risco. É calculado como resultado da combinação
29
entre a probabilidade e o impacto. Pode assumir os valores entre 0,1 (10% x 1)
a 4,5 (90% x 5), sendo esta maior exposição possível – riscos com esta
classificação devem ser tratados imediatamente e acompanhados de perto
pelos interessados do projeto.
Haverá uma matriz contemplando os riscos positivos e outra para os
ricos negativos para que ambos os tipos de riscos possam ser analisados
separadamente.
Figura 6: Diagrama de Exposição de Risco (Dinsmore, 2010 –
Universidade Corporativa, Módulo11, pág. 18).
6.7- Resposta aos riscos
O processo planejamento de respostas a riscos é responsável pelo
desenvolvimento de opções e determinação de ações para aumentar as
oportunidades e reduzir as ameaças dos riscos aos objetivos do projeto.
6.8- Ações para tratamento do risco Durante o registro dos riscos na documentação do projeto é necessário
especificar ao longo de sua análise, e antecipar ações para prevenção, a fim
30
de tratar o risco negativo, no sentido de que o mesmo não evolua para um
problema de contingência, a fim de mitigar o risco negativo, caso o mesmo já
tenha se configurado em um problema e a fim de explorar o risco para serem
tomadas ações para que o risco positivo aconteça. Além disso, outras
informações devem ser registradas como, por exemplo, o tipo de estratégia de
ação a ser incorporada, o responsável pelo tratamento do risco e uma data
limite para realização da ação.
A atividade de estabelecimento de ações para tratamento dos riscos
está embutida nas atividades de dois até quatro do processo geral
apresentado no planejamento do gerenciamento de riscos.
Segue o presente processo que detalha o parâmetro de estratégia de
ação presente nas documentações de registros, e suas valorações pré-
definidas, conforme a figura abaixo:
6.9- Estratégia de ação para os riscos negativos
Figura 7 – Estratégia de Ação (Dinsmore, 2010 – Universidade
Corporativa, Módulo 11, pág. 20).
31
6.10- Estratégia de ação para os riscos positivos
Figura 8 – Estratégia de Ação (Dismore,2010 – Universidade
Corporativa, Módulo 11, pág. 20).
6.11- Gerenciamento de riscos e questões Além do Gerenciamento de Riscos, o projeto: Sistema de Atendimento
de Pacientes conduzirá práticas relacionadas ao Gerenciamento de Problemas
ou questões.
Os problemas descrevem situações já ocorridas e que precisam de
respostas imediatas para controle e limitação de impactos adversos.
Problemas, tipicamente, são consequência de riscos negativos não
tratados de forma adequada.
Figura 9 – Identificação e Impacto de Risco (Dinsmore, 2010 –
Universidade Corporativa – Módulo 11, pág 23).
32
CAPÍTULO VII
PLANO DE LIÇÕES APRENDIDAS
7.1- Objetivo Este procedimento tem por objetivo estabelecer a sistemática de
realização do processo de lições aprendidas dos projetos que fazem parte do
projeto: Sistema de Atendimento de Pacientes.
7.2- Processo de lições aprendidas O processo de lições aprendidas constitui uma prática de gestão do
conhecimento, empregada na análise de ocorrências relevantes, inovadoras ou
cujos resultados foram inesperados, de forma a registrar as experiências,
acertos e erros, e promover a disseminação deste conhecimento na empresa.
7.3- Objetivos do processo de lições aprendidas O processo de lições aprendidas faz parte de um objetivo maior para
gerar aprendizado, exercitando através destas atividades de estruturação do
conhecimento tático, o aprendizado organizacional contínuo.
Com a concretização deste objetivo, teremos benefícios que logo serão
percebidos, tais como: propiciar melhorias nos processos de planejamento e
execução dos projetos a partir das experiências decorrentes dos acertos e
erros, conscientizar a equipe sobre o valor da reflexão sobre os acertos e erros
dos processos, disseminar as lições aprendidas por toda a organização ou
grupos de interesse, para replicar sucessos e evitar a repetição dos erros,
aumentar a previsibilidade dos projetos, melhorar sensivelmente a
33
comunicação, valorizar o trabalho em equipe, superar os níveis de qualidade
esperados, melhorar o aproveitamento em treinamentos e demais atividades
de transferência de conhecimentos e gerar uma rápida assimilação de
mudanças e novos processos.
7.4- Sistemática do processo de lições aprendidas
A forma de registro das informações será classificada em itens de
conhecimento, que são: alerta técnico que diz respeito à comunicação de
procedimentos que levam a resultados indesejáveis ou a outros fatos que
exijam atenção; melhores práticas que é a boa ideia, ou seja, esta prática
possui aplicação específica, faz sentido intuitivamente, porém não há
experiência suficiente que suporte sua ampla utilização; melhor prática local
que trata-se de uma técnica, metodologia e procedimento o ou processo que
tenha sido implementado e que tenha melhorado os resultados nos negócios
onde foi aplicado.
7.5- Lições aprendidas Nada mais é que a narrativa de uma experiência inovadora ou cujos
resultados foram inesperados de forma a registrar a experiência, acertos e
erros.
Esta narrativa é organizada de acordo com os seguintes
questionamentos: o que era esperado acontecer, qual a descrição dos
resultados esperados ao iniciar a experiência, o que realmente aconteceu, qual
a descrição dos resultados que de fato aconteceram, por que acorreram as
diferenças, a análise dos motivos pelos quais aconteceram diferenças entre o
que era esperado e o que de fato correu e o que podemos aprender?
Para a estruturação de uma narrativa consistente é necessário que haja
o conhecimento do que trata lições aprendidas, como se realiza a busca desta
informação, como se formaliza ela, sua consolidação e, por último, sua
34
1. Consulta de Lições Aprendidas, Melhores Práticas e Alertas Técnicos no início de cada fase
2. Realização de Divulgação de Lições Aprendidas, Alertas Técnicos e Melhores Práticas do Projeto em Evento de Encerramento da Fase
Iniciação Planejamento Execução Monitoramento
Encerramento
validação. Estes quatro passos são fundamentais e após a validação teremos
uma lição aprendida que pode ser publicada e compartilhada com todos da
empresa.
7.6- Lições aprendidas durante o ciclo de vida dos projetos O processo de lições aprendidas é contínuo e deve ser feito durante
todo ciclo de vida do projeto.
Figura 10 – Grupo de Processos (Dinsmore, 2010 - Universidade
Corporativa – Módulo 4, pág. 7).
7.7- Preparação do evento de lições aprendidas Nesta etapa, deve-se preparar a agenda, definir os grupos, indicar o
nome do coordenador de cada grupo, realizar um levantamento prévio dos
desvios e organizar a logística do evento.
Sugere-se no mínimo meio dia para realização do evento, podendo este
ser ampliado em função do volume de informações relacionadas.
35
Teremos, no evento, quatro momentos: abertura e apresentação dos
objetivos e nivelamento de conceitos, divisão dos grupos (definir um grupo
multidisciplinar, envolvendo membros da equipe, de áreas e frentes diferentes),
Identificação e/ou análise das lições aprendidas por cada grupo e consolidação
e aprovação das lições aprendidas por todos os participantes do evento.
7.8- Realização do evento de lições aprendidas O gerente do projeto tem o papel de facilitador e é o responsável por
provocar discussões que motivem e ajudem os participantes a aprender como
grupo e zelar para que as discussões atendam às quatro questões básicas,
facilitando o entendimento do que será posteriormente consolidado e
apresentado para toda a equipe.
A discussão sobre as experiências, acertos e erros deve ser de caráter
impessoal, evitando associar os desvios e pontos negativos identificados ao
nome de pessoas. O papel do gerente de projeto é muito importante para
garantir que o foco do trabalho seja identificar "o que devemos repetir" e "o que
devemos evitar", impedindo discussões de outro cunho.
O gerente do projeto não deve permitir que as conclusões e
recomendações ou mesmo o registro das ações realizadas sejam usados para
censurar ou punir pessoas envolvidas no processo. Ao contrário, o registro dos
acertos e erros cometidos deverá ser um fator positivo na avaliação da equipe
e de seus membros.
7.9- Lições aprendidas e a ética dos envolvidos no projeto
Talvez você esteja questionando o que tem a ética com as lições
aprendidas?
36
Nos dias atuais a competição dentro dos projetos é causadora de
fatores desmotivantes e até de condutas que ferem os padrões da ética
estabelecida primeiramente pela sociedade.
Toda empresa precisa possuir seus padrões de ética e costumes para
proteger a si mesma e aos profissionais que passam por ela.
O próprio PMI possui seu código de ética que é dividido em quatro
sessões fundamentais sendo estas: a responsabilidade que é subdividido em
outras duas subseções que são os padrões de conduta desejável e obrigatória.
Esta sessão aborda sobre o compromisso em assumir as decisões que
tomamos ou deixamos de tomar, ações e consequências delas resultantes; o
respeito que aborda sobre como o profissional deverá lidar com as pessoas, e
pelos recursos a ele confiados (dinheiro, reputação, segurança das pessoas\)
de forma respeitosa.
Um ambiente de respeito aumenta a confiança e a excelência de
desempenho através da promoção de uma cooperação mutua e da valorização
de novas perspectivas e visões.
A equidade que além do dever de assumir nossas decisões, temos
ainda o dever de tomar essas decisões de forma imparcial e objetiva,
realçando e eliminando os possíveis interesses próprios, preconceitos,
favoritismos.
A honestidade: que é outro dever que esta sessão aborda o dever de
agir de maneira sincera e dentro da lei em nossa comunicação e conduta, e
isso deverá está de acordo com a localização ou país ao qual o profissional
esteja desenvolvendo suas atividades.
37
O PMI ao revisar seu código de ética incluiu em uma nova versão o
fornecimento de informações de ética e conduta obrigatórias e desejáveis para
todos os membros, profissionais certificados e profissionais que desejam se
certificar, de forma mais detalhada.
Com tantos exemplos ruins que existem dentro de projetos, como as
devido politicagens existentes dentro das empresas que tentam manipular o
projeto e interesses pessoais, é necessário que o gerente de projeto não anule
a importância de registrar nas lições aprendidas procedimentos que não foram
adequados e feriram a ética da empresa do cliente, da própria empresa
prestadora de serviços ou implementadora e do projeto em si para tirar proveito
no futuro de experiências que tragam habilidades pessoais e evite
constrangimentos futuros.
7.10- Consolidação das lições aprendidas
As lições aprendidas após consolidadas trata-se muito mais do que um
documento para cumprir a formalidade do projeto. São as informações que
permitirão que os erros passados não se repitam e os acertos possam ser
feitos novamente. Por isso é importante registrar tanto as boas quanto as más
experiências do projeto. Estes registros ajudarão a moldar as atividades e
controles dos projetos futuros.
A forma de fazer a documentação de lições aprendidas varia muito de
uma organização para outra (ou de um projeto para outro). A maioria das
empresas mesmo as que adotaram o gerenciamento de projetos de uma forma
ou outra, não possuem uma forma única de criar estes registros. Cabe ao
gerente de projeto tomar a iniciativa para criar algo que seja adequado a sua
estrutura e consolidar da melhor forma possível.
38
De qualquer forma na elaboração desta pesquisa foi apresentado um
modelo que será útil para todos que buscarem o conhecimento descrito neste
trabalho.
É importante que quem documentar as informações como descrito no
plano de lições aprendidas, procure se lembrar que elas precisam estar claras
para serem compreendidas por qualquer pessoa que irá se utilizar dela.
A consolidação sugerida são as respostas em forma de apresentação a
ser realizada e enviada para toda a equipe do projeto contendo os resultados
dos trabalhos dos grupos, com as conclusões e sugestões em relação aos
pontos analisados.
Desta forma todos os envolvidos no projeto possuem a oportunidade de
aprender com sua trajetória.
39
CONCLUSÃO
O mercado possui suas necessidades e projetos nascem de suas
demandas.
Um projeto precisa ser planejado e não somente executado sem
critérios para que persiga o objetivo de devolver ao mercado um projeto com
excelência, planejado e capaz de não deixar lacunas no que se propôs.
Nesta pesquisa foi indicada uma metodologia de riscos baseada nas
melhores práticas do PMI e acreditem: em um projeto existem muitos riscos,
mas eles podem se tornar oportunidades quando bem entendidos e
respondidos.
O objetivo desta pesquisa é incentivar gerentes de projetos a
disponibilizarem tempo para planejar e não somente executar. Pois quando se
planeja o alvo torna-se mais próximo de ser alcançado.
Foram mencionados alguns planos que são necessários ao bom início
do projeto, como o de escopo e requisitos, pois é de alta responsabilidade do
gerente de projeto entender o escopo e levantar adequadamente os requisitos
do projeto para que o mesmo seja um sucesso.
As lições aprendidas fez parte desta pesquisa, pois é muito importante
registrarmos o que deu certo e o que não deu certo, especificando o motivo de
cada ação.
Se pararmos para analisar tudo na vida deveria contemplar as lições
aprendidas.
40
Infelizmente muitos projetos fracassam e não registram o que ocorreu.
As lições aprendidas devem ser uma prática para a construção da melhoria
contínua.
É certo que o interesse em inserir nesta pesquisa o plano de lições
aprendidas possui o objetivo de orientar o gerente de projeto para que ele
visualize que esta é uma ferramenta essencial para seu crescimento
profissional e para a melhoria contínua de todos os envolvidos.
41
ANEXOS
Índice de anexos
Anexo 1 >> Termo de Abertura; Anexo 2 >> Matriz de Responsabilidade de Recursos; Anexo 3 >> Matriz de Interdependência do Escopo; Anexo 4 >> Matriz de Gestão de Mudança; Anexo 5 >> Dicionário da EAP.
42
ANEXO 1
TERMO DE ABERTURA – AVM, 2011.
43
ANEXO 2
MATRIZ DE RESPONSABILIDADE DE RECURSOS - PMI, 2004.
Oda
ir M
arco
des
Filh
o
RPPapéis Responsável
Participante da equipe
Recursos Humanos
Pacotes de Trabalho/ Atividade
Matriz de Responsabilidade
Projeto : Sistema de Atendimento de Pacientes
44
ANEXO 3
MATRIZ DE INTERDENPENDÊNCIA DO ESCOPO - PMI, 2004.
Pacotes de Trabalho/Atividades
Data de Início
Data de Término
Sucessora Predecessoras
Matriz de Interdependência de Escopo
45
ANEXO 4
DECLARAÇÃO DO ESCOPO – PMI, 2004.
46
ANEXO 5
Matriz de Gestão de Mudança – PMI, 2004.
Papéis e Responsabilidades
Papel Responsabilidades Participante (S)
Comitê de Controle de Mudanças (CCM)Autorizar ou Rejeitar as mudançaspropostas sobre o escopo, prazo e orçamento do projeto.
Patrocinador - Gerente do Projeto - Stakeholder selecionado
Gerente de Mudanças
Identificar mudanças, avaliar impactos das mudanças sobre os aspectos de escopo, custo e prazo.Documentar e submeter as solicitações de mudanças ao CCM;Controlar os baselines.
Gerente do Projeto
Solicitante
Solicita a mudança (normalmente de escopo)
Patrocinador - Gerente do Projeto - Stakeholder / Equipe
Avaliação de Impacto da Mudança
Tipo de Mudança Análise de Impacto
Escopo
Avaliar- Plano de trabalho;- Custo adicional;- Prazo adicional;- Riscos associados a mudança de escopo
Cronograma
Avaliar- Alteração no prazo final;- Ações corretivas (reduzir ou ampliar escopo e custo associado);- Riscos.
Custo
Avaliar - Ações corretivas;- Custo final do projeto;- Riscos.
47
Identificação WBS
Pacote de Trabalho Descrição Critério de Aceitação
Dicionário da EAP
ANEXO 6
Dicionário da EAP – PMI, 2004.
48
BIBLIOGRAFIA CONSULTADA
1- DINSMORE, Paul. Gerenciamento de Projeto. Preparatório para
certificação PMP. 4ª. Ed. RJ, Editora Qualitymark, 2010.
2- MAXIMIANO, Antonio Cesar Amaru. Como Transformar Ideias em
Resultados. 3ª Ed. RJ, Atlas, 2009.
3 - PMI. Um guia de conhecimentos em gerenciamentos. Guia PMBOK® -EUA
Project Management Institut, Edição 2008.
4- VARGAS, Ricardo V. Manual Prático do Plano de Projeto. 4ª Ed. RJ,
Brasport, 2009.
49
ÍNDICE
FOLHA DE ROSTO 2
AGRADECIMENTO 3
DEDICATÓRIA 4
RESUMO 5
METODOLOGIA 6
SUMÁRIO 7
INTRODUÇÃO 8
CAPÍTULO I
A Investigação do Projeto 10
CAPÍTULO II
Plano de Gerenciamento de Escopo 12
2.1 – Objetivo 12
2.2 – Descrição dos processos 12
2.3 – Planejamento do escopo 12
2.4 – Definição do escopo 13
2.5 – Criação da Estrutura Analítica do Projeto 13
2.6 – Linha de base do escopo 15
2.7 – Verificação do escopo 15
2.8 – Controle do escopo 15
2.9 – Matriz de rastreabilidade de requisitos 16
CAPÍTULO III
Mudanças e o Ciclo de Vida do Projeto 17
3.1 – Quando deve ser acionado 17
3.2 – Quem participa 17
50
CAPÍTULO IV
Ciclo de Vida do Produto 19
4.1 – Etapas do trabalho 19
CAPÍTULO V
Plano de Gerenciamento de Requisitos 21
5.1 – Objetivos 21
5.2 – Descrição dos Processos 21
5.3 – Planejamento do plano de gerenciamento de requisitos 21
5.4 – Garantia da rastreabilidade 23
5.5 – Monitoramento e controle 23
5.6 – Controle de mudanças 23
CAPÍTULO VI
Plano de Gerenciamento de Riscos 25
6.1 – Objetivo 25
6.2 – Planejamento de gerenciamento de riscos 25
6.3 – Análise qualitativa dos riscos 26
6.4 – Análise quantitativa dos riscos 26
6.5 – Natureza e categoria dos riscos 27
6.6 – Probabilidade e impacto dos riscos 27
6.7 – Resposta aos riscos 29
6.8 – Ações para tratamento do risco 29
6.9 – Estratégia de ação para os riscos negativos 30
6.10 – Estratégia de ação para os riscos positivos 30
6.11 – Gerenciamento de riscos e questões 31
CAPÍTULO VII
Plano de Lições Aprendidas 32
7.1 – Objetivo 32
7.2 – Processo de lições aprendidas 32
51
7.3 – Objetivos do processo de lições aprendidas 32
7.4 – Sistema do processo de lições aprendidas 33
7.5 – Lições aprendidas 33
7.6 – Lições aprendidas e o ciclo de vida dos projetos 34
7.7 – Preparação do evento de lições aprendidas 34
7.8 – Realização do evento de lições aprendidas 35
7.9 – Lições aprendidas e a ética no projeto 35
7.10 – Consolidação das lições aprendidas 37
CONCLUSÃO 39
ANEXOS 41
BIBLIOGRAFIA CONSULTADA 48
ÍNDICE 49
ÍNDICE DE FIGURAS 52
FOLHA DE AVALIAÇÃO 53
52
ÍNDICE DE FIGURAS
Figura 1 – Diagrama de Integração 14
Figura 2 – Diagrama de Riscos 26
Figura 3 – Diagrama de Registro de Riscos 27
Figura 4 – Metodologia de Riscos 28
Figura 5 – Metodologia de Riscos 28
Figura 6 – Diagrama de Exposição de Riscos 29
Figura 7 – Estratégia de Ação 30
Figura 8 – Estratégia de Ação 31
Figura 9 - Identificação e Impacto de Risco 31
Figura 10 – Grupo de Processos 34
![UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO … · [digite texto] universidade candido mendes pÓs-graduaÇÃo “lato sensu” avm faculdade integrada " fiscalidade e mÍnimo existencial](https://img.document.onl/doc/110x75/5bec469009d3f231188cd88a/universidade-candido-mendes-pos-graduacao-digite-texto-universidade-candido.jpg)
