terça-feira, 26 de junho de 2012

Definindo Percentual de Complitude no MS-Project

Muitos colegas meus tem dúvidas quanto a utilização e conceito do percentuais apresentados no MS Project, neste pequeno texto  pequeno texto procuro elucidar a diferença entre % Complete, % Work Complete e %  Phisical  Complete, aproveitem e monitorem seus projetos !

O MS-Project contém três medidas :
  • % Complete - baseado na duração da atividade, exemplo, suponha atividade com duração de 10 dias com 40 % Complete ao final do quarto dia do início da atividade, MS-Project indicará que esta atividade estará atrasada se o valor do % Complete for menor que o valor esperado do status date do projeto



No caso acima:
% Complete: (50 % * 7 dias) + (30 % 5 dias) + (65 % 3 dias) / 5 + 7 + 3 = +- 43,66 %
  • % Work Complete - é baseado no número de horas completadas, outra medida calculada pelo MS-Project . Por exemplo, dois recursos serão carregados nas tarefas abaixo, acompanhe a sequência:








A maior parte das horas é carregada nos primeiros três dias, usando a mesma porcentagem acima a fórmula ficaria:
% Work Complete: (50% * 40) + (30 % * 14) + (65 % * 12)/ 40+14+12 = 48,48 %
  • % Phisical Complete - quando unidade de medida é desejada, baseline é requerido e o cálculo é basedo nos custos envolvidos, neste caso o custo do projeto é demonstrado abaixo:



Para este momento o project status date será movido para o futuro, último ida do projeto


% Phisical Complete : (50 % * 3.440) + (30 % * 1.204) + (65% *228) / 3.440+1.204+228 = 46 %

Conclusão:

Embora a possibilidade exista que as medidas poderiam ser iguais sob certas circunstâncias, em geral elas não são numericamente iguais,se um projeto esta no prazo, a tabela abaixo irá mostrar o % acumulado de cáculo para cada tipo de métrica:


Graficamente o resultado seria:



Por definição o crescimento do % Complete so ocorre se a tarefa estiver no sempre no prazo

Nelson Rosamilha, PMP,BB


Twitter: nelsonrosamilha (siga-me , todo dia tem algo novo de gestão de projetos que pode ajudá-lo, inclusive, vagas de empregos)
Linkedinhttp://br.linkedin.com/in/rosamilha

quinta-feira, 21 de junho de 2012

Os documentos essenciais para gestão de projetos


Hoje resolvi escrever um pouquinho sobre documentação mínima para voce gerir seu projeto com segurança e efetividade. Durante cada fase do ciclo de vida do projeto, isto é,  iniciação, planejamento, execução e encerramento  há os documentos essenciais 
que precisam ser criados de modo a assegurar que tenhamos um projeto de sucesso. Não quero dizer aqui que isto é uma verdade, mas é um caminho !








Esses documentos apoiam o projeto durante seu ciclo de vida e tem papel fundamental ! 


Recomendo aqui como melhores práticas uma lista por fase do projeto que podeajudá-lo:

  • Fase de iniciação:

  1. Business Case – Documento que contem custos e benefícios do projeto de modo que sponsor saiba qual será o retorno sobre o investimento (benefício).
  2. Estudo de viabilidade – Para garantir que o projeto seja viável antes do kick off .
  3. Project Charter – Termo de Abertura onde é registrado os objetivos do projeto, escopo, equipe, premissas, restrições, prazos e resultados finais.

  • Fase de planejamento:

  1. Plano de projeto – Deve ser concluído durante a fase de planejamento e,  irá listar todas as fases, tarefas e subtarefas que precisam ser feitas e quando para completar o projeto.  
  2. Planejamento de recursos – Plano de alocação de recursos necessários no projeto, incluindo financeiro, equipamentos e outros recursos materiais.
  3. Plano de qualidade –  Documente os requisitos da qualidade , contra a qual os seus resultados serão medidos para garantir a satisfação do cliente.
  4. Plano de risco – Riscos não documentados..não são gerenciados ! Para gerenciar riscos de forma eficaz, documente a probabilidade e o impacto de cada risco e o plano de resposta ao risco. Atribua responsáveis para cada risco
  5. Plano de comunicação  Comunicação eficaz  com as partes interessadas no momento certo com a informação correta !

  • Fase de execução:

  1. Gestão de Mudança Cada mudança no projeto deve ser documentada permitindo a correta priorização e controle de alterações.
  2. Gestão de Risco – gerenciamento de riscos em curso devem ser documentados em  formulário do risco e monitorados.
  3. Gestão de Issues  – registre os issues em uma diário de bordo ou formulário a medida que surjam  e adicione ações para resolvê-los de forma eficaz e rápida.
  4. Gestão do tempo – gerencie o tempo da equipe no projeto através de ferramentas e atualize  seu plano de projeto continuamente.
  5. Gestão de custos  – gestão financeira do projeto é gerenciar usando os formulários de despesas e planilhas de orçamento. Cada despesa deve ser registrada e aprovada para garantir que você acompanhe isso contra o orçamento original do projeto como se fosse sua empresa

  • Fase de encerramento:

  1. Relatório de encerramento: Quando um projeto chega ao fim, é importante documentar todas as ações e etapas necessárias para encerrar o projeto. Isso deve incluir  mudança de pessoas, equipamentos e materiais.
Boa sorte no seu projeto !

domingo, 17 de junho de 2012

Método 8D de Solução de Problemas


Quem nunca herdou ou executou um projeto de produto ou  serviço ou projeto com problemas  de qualidade  que atire a primeira pedra...ou melhor, quem nunca teve que reclamar dos famosos problemas recorrentes?  Pois é...bem corriqueiro não ? 

O  “o método das 8 disciplinas”  indica  como se deve agir para resolver de verdade um problema, de verdade porque tenta-se acabar com problemas recorrentes. Este método foi utilizado pela primeira vez em 1987 pelo governo do EUA (8D-like).

O método das 8 disciplinas, é uma abordagem para solução de problemas ocorridos em produtos ou processos que  tem o intuito de identificar, corrigir e eliminar problemas recorrentes. 


A ideia é aumentar a sinergia entre os indegrantes da equipe de modo que todos possar dar sua contribuição para a solução do problema. 


No 8 D acredita-se que, a equipe (o todo) é melhor do que a soma dos seus membros (partes). Desta forma as indicações para solução de problemas se dá pela ação da equipe. 


Na figura abaixo discorro sobre as etapas:

 1 – Estabelecimento (Formação) da Equipe 

Nesta etapa faz se a definição dos membros da equipe que trabalharão para solução do problema, a 
definição dos papeis de cada membro é muito importante é espinha dorsal para o sucesso no processo de tomada de decisão
manter a equipe certa é o que definirá a solução efetiva.  Um ponto importante fica para o líder da equipe, este deve ter as habilidades de líder e das ações necessárias para sanar o problema:
  • Selecionar membros da equipe de diversas áreas que possuam conhecimento do produto e do processo e que possam auxiliar na resolução do problema identificado;
  • Verifique se a equipe possue o tamanho adequado e o apoio necessário
2 – Descrição do Problema

O problema é descrito em termos mensuráveis, verifica-se o mesmo é interno ou externo. Nesta etapa é que se tem em detalhes a localização e o definição clara do problema. Geralmente para identificação e detalhamento do problema usa-se o método 5W2H: O que (What), Quando (When), Quem (Who), Onde? (Where), porque? (Why), Como? (How) e Quanto (How much).


Saber realmente definir o problema é o meio caminho para uma solução efetiva!


3 – Desenvolvimento de plano de contenção Provisório

Quando o problema estiver ocorrendo, pode-se pensar em uma ação paliativa (acho que esta é a palavra ideal), o problema não é resolvido por completo, mas há um bloqueio momentâneo até que se encontre a solução definitiva, isto é, isole o efeito do problema até que sejam implementadas as ações corretivas).


Uma ação de contenção eficaz minimizará o efeito negativo que o  problema trouxe ao cliente


4 – Definição e Verificação da Causa(s) Raiz

Nesta etapa são identificadas todas as causas essenciais que podem explicar a ocorrência do problema, São testadas as causa potencias e identifica-se as alternativas de ações para eliminação desta causa raiz. Para a verificação das causas raízes é utilizado o ‘Diagrama de causa e efeito’.


Causas que quando excluidas resultarão na eliminação total do problema

5 – Definição das Ações Corretivas Permanentes

Após a definição das causas básicas, são definidas as ações de correção a serem aplicadas nesta causa para que o problemas seja resolvido de forma permanente. Quando ocorre de através de um ‘brainstorn‘ a equipe chegar a mais de uma solução para a causa, pode se escolher a melhor ou prioritária usando o consenso da equipe.


A escolha deve ser bem estudada para economizar recursos


6 – Avalie e Executar Ações Corretivas Permanentes (Figura da SETA) 

Nesta etapa é feita a verificação da eficácia das ações permanentes, aplicada as causas raízes. Faz-se o controle das ações de modo que se assegure a eliminação da causa raiz.

               A ação correta implantada é bem controlada e significa o problema resolvido

7 – Evitar (Impedir) Recorrências

Este é ponto final da resolução do problema, nesta etapa é necessário que se tenha uma ceta segurança quanto a resolução definitiva do problema. A causa raiz e analisada de maneira a impedir que o problema, ou um similar venha ocorrer.


É melhor prevenir do que remediar


8 – Reconheça a Equipe

Nesta etapa, o problema deve estar resolvido, e a não reincidência assegura. Aqui são feitos os reconhecimento tanto da equipe, quando dos esforços individuais. Por fim, o compartilhamento do conhecimento adquirido na resolução do problema deve ser compartilhado com toda a organização.


O reconhecimento é essencial!!!




Esta disciplina pode ser aplicada a qualquer área, para os colegas de Tecnologia de Informação, ai vai minha recomendação, as atividades de testes no desenvolvimento de software são de alguma forma o ponto de melhor encaixe destas disciplinas. Isso não que dizer é claro que o conjunto de etapas não possa ser aplicado no processo de desenvolvimento como um todo.




terça-feira, 12 de junho de 2012

Método de Simulação de Monte Carlo

Antes de falarmos sobre este método é importante o conceito, a palavra simulação refere-se a qualquer método analítico cuja intenção é imitar algum sistema real, principalmente quando outras análises são matematicamente complexas.
Dessa forma, o objetivo da simulação é descrever a distribuição e características dos possíveis valores de uma variável dependente, depois de determinados os possíveis valores e comportamentos das variáveis independentes a ela relacionadas.Em muitos casos, os modelos de simulação são utilizados para analisar uma decisão envolvendo risco, ou seja, um modelo no qual o comportamento de um ou mais fatores não é conhecido com certeza. Neste caso, estes fatores são conhecidos como variável aleatória, e o seu comportamento é descrito por uma distribuição de probabilidade (MOORE;WEATHERFORD, 2005). 
O nome "Monte Carlo" surgiu durante o projeto Manhattan na Segunda Guerra Mundial. No projeto de construção da bomba atómica, Ulam, von Neumann e Fermi consideraram a possibilidade de utilizar o método, que envolvia a simulação direta de problemas de natureza probabilística relacionados com o coeficiente de difusão do neutron em certos materiais. Apesar de ter despertado a atenção desses cientistas em 1948, a lógica do método já era conhecida há bastante tempo. Por exemplo, existe um registro de um artigo escrito por Lord Kelvin dezenas de anos antes, que já utilizava técnicas de Monte Carlo em uma discussão dasequações de Boltzmann. (Fonte: Mundo PM).
Esta metodo está associado diretamente a gestão de riscos em projetos, sendo uma das análises quantitativas mais utilizadas para custo, prazo e risco, esta técnica é destacável nos problemas de cenários “e se?”, ou seja, e se a situação representada pelo cenário “X” ocorrer? E se acontecer uma greve, atrasos na entrega ou outros fatores incontroláveis?  O método maximiza a competitividade principalmente em projetos de médio ou grande porte, onde a aplicação não automatizada de cenários “e se?” se torna uma tarefa árdua. 
Outro benefício é o ganho de tempo proporcionando uma visão mais profunda do planejamento; ele permite também se calcular por meio de iterações o custo do projeto ou o cronograma do projeto várias vezes usando valores de entrada selecionados aleatoriamente a partir de distribuições de probabilidade dos possíveis custos ou durações para calcular uma distribuição do custo total possível do projeto ou de datas de término.

Como funciona o método de Monte Carlo

A simulação de Monte Carlo é um processo de amostragem cujo objetivo é permitir a observação do desempenho de uma variável de interesse em razão do comportamento de variáveis que encerram elementos de incerteza. Embora seja um conceito simples, a operacionalização desse processo requer o auxílio de alguns métodos matemáticos. Algumas etapas do processo de simulação incluem o desenvolvimento conceitual do modelo do sistema ou do problema a ser estudado, 

A construção do modelo de simulação inclui:
  • desenvolvimento de fórmulas e equações apropriadas,
  • coleta de dados necessários,
  • determinação das distribuições de probabilidades associadas às variáveis de entrada e,
  • construção ou definição de uma forma para registrar os dados
  • verificação e a validação do modelo
Em seguida é necessário executar o desenho de experimentos com a utilização do modelo: tal etapa envolve a determinação de questões a serem respondidas pelo modelo com o intuito de auxiliar o decisor a alcançar o seu objetivo; a realização dos experimentos e análise dos resultados: finalmente, nessa última etapa, com base no desenho de experimento feito, as simulações são realizadas para que se obtenha o conjunto de informações especificado, que pode ser transmitido aos tomadores de decisão em forma de relatórios.  


Resumindo


Enquanto uma forma de realizar previsões com 100% de certeza em qualquer que seja o evento é pouco provável, a simulação do MMC oferece recursos para tornar conhecida a probabilidade da ocorrência de determinado acontecimento. A proximidade do resultado obtido está ligada diretamente ao modelo desenvolvido, uma vez que este é a base de toda a simulação a ser realizada.
O MMC proporciona ao gerente de projetos uma poderosa ferramenta que aliada a boas práticas de gestão de projetos resultará em planejamentos mais robustos que inclui fontes mais confiáveis de informação sobre as estimativas apresentadas para o projeto. Com isso, torna-se desnecessária a utilização de técnicas como o tão conhecido “chute”, por exemplo....

Quer saber mais ?

Ferramenta - @Risk - Palisade

Contribuição de colega de rede !!!



Em 1654, época em que o Renascimento estava em pleno alvorecer, o cavaleiro de Méré, um nobre francês com gosto pelo jogo e pela matemática, desafiou o famoso matemático francês  Blaise Pascal a decifrar um enigma.  A pergunta era como dividir as apostas de um jogo de azar,  entre dois jogadores, que foi interrompido quando um deles esta vencendo. O enigma confundira os matemáticos desde sua formulação, duzentos anos antes, pelo monge Luca Paccioli. Este foi o homem que trouxe a contabilidade das partidas dobradas à atenção dos homens de negócios da época – ensinou as tabuadas de multiplicação a Leonardo da Vinci.  Pascal pediu ajuda a Pierre de Fermat, advogado que também era brilhante matemático. O resultado de sua colaboração foi pura dinamite intelectual. O que poderia parecer uma versão do século XVII do jogo da Busca Trivial levou à descoberta da teoria das probabilidades, o núcleo matemático do conceito de risco. Assim nasceu a Simulação de Monte Carlo, uma referência ao Bairro Monte Carlo, em Mônaco, onde ocorriamm e ainda ocorrem, os jogos.

quinta-feira, 7 de junho de 2012

Ferramenta de Qualidade - Diagrama de Afinidade

Diagrama de Afinidade



O diagrama de afinidade organiza um grande número de idéias em suas relações naturais, este método explora a criatividade de uma equipe e intuição e, foi criado  em 1960 pelo japonês Jiro Kawakita antropólogo. 
O diagrama de afinidade é usado para organizar em  grupos um grande número de idéias, opiniões, ou  preocupações relativas a determinado tópico, esta ferramenta é utilizada normalmente  na fase de planejamento da qualidade com o objetivo de se conhecer o problema por meio da organização das idéias.
 O processo se destina a estimular a criatividade e a participação total. Ele funciona melhor com grupos de tamanho limitado (é recomendado, no máximo, oito participantes), onde as pessoas estão acostumadas a trabalhar juntas. Esta ferramenta é usada freqüentemente para  organizar as idéias geradas por brainstorming.


Resumindo:


Para se construir o Diagrama de Afinidade, devemos pensar no problema em questão, suas causas e, posteriormente separar estas causas em categorias, através de afinidades. É originado pelo Brainstorming e torna-se um complemento do Ishikawa, porém com aplicações mais amplas (por exemplo, o que pode ser importante na qualidade de um aparelho celular? Cada envolvido dirá o que considera importante, posteriormente estes itens serão separados por categorias e esta separação ocorre pela afinidade dos itens levantados). 




Quando usar um Diagrama de Afinidade ?


  • Quando você se depara com muitos fatos ou idéias em aparente caos..
  • Quando questões parecem grandes e complexas para compreensão.
  • Quando o consenso do grupo é necessário
  • Depois de um exercício de reflexão
  • Ao analisar os dados verbais, tais como resultados da pesquisa.
  • Fornecer suporte para inovação de conceitos tradicionais
  • Organizar as idéias resultantes de algum processo de avaliação, como na auditoria da qualidade;
  • Planejar a coleta de dados para futura Estratificação

Roteiro para construção:

  1. Gerar os dados para construção do diagrama de afinidades
  2. Espalhe os dados resultantes sobre a mesa, de modo que todos possam vê-los
  3. Forme grupos de dados, contendo no máximo 5, com alguma característica comum.
  4. Identifique cada grupo pela característica comum de agrupamento e registre-a no cartão título, que deverá ter alguma marca, para diferenciá-lo dos cartões de dados.
  5. Prenda cada grupo ao seu cartão título, de modo que apenas que apenas este último esteja visível.
  6. Repita os passos 3, 4, 5 usando os cartões título como cartões dados.
  7. Repita os passos, 3, 4, 5 para cada novo conjunto de cartões título criados, até que você tenha, apenas, um grupo contendo no máximo 5 cartões títulos.
  8. Comece a construção do diagrama pelos pequenos grupos iniciais; construa um retângulo envolvendo cada grupo.
  9. Sobre o lado superior do retângulo coloque o cartão título do grupo
  10. Envolva, com um retângulo, os retângulos cujo título forma um grupo

Fica aqui a dica: Para manipular com eficiência diagramas de afinidades a Microsoft Office Labs oferece gratuitamente o software StickySorter, bastante útil para profissionais, estudantes e qualquer um que queira estimular o processo criativo em busca de soluções para problemas. (http://www.microsoft.com/portugal/educacao/suiteaprendizagem/stickySorter.html)

Exemplo de um diagrama de Afinidade






domingo, 3 de junho de 2012

FMEA – ANÁLISE DO MODO E EFEITOS DE FALHA - Gerencie seus riscos !


A metodologia de FMEA foi criada pela NASA em meados de 1960. Nesta época foi utilizada como método de análise preventivo dos potenciais modos de falha do projeto Apolo. 


FMEA é um método sistemático de análise que oferece três funções distintas:

Ferramenta – é uma das técnicas de baixo risco mais eficientes para prevenção de problemas e identificação das soluções mais eficazes em termos de custos, a fim de prevenir esses problemas;
Procedimento – oferece uma abordagem estruturada para avaliação, condução e atualização do desenvolvimento de projetos. Pode ser utilizada para associar e manter vários outros documentos da organização.
Diário – inicia-se na concepção do projeto e se mantém durante todo o ciclo de vida. Qualquer modificação durante esse período, que afete a qualidade ou a confiabilidade do produto, deve ser avaliada e documentada na FMEA.


Como Funciona?


O método propõe a quebra de sistemas em componentes inferiores e, em seguida, a análise estruturada desses componentes ou subsistemas para se evidenciar os modos de falha potenciais antes que sejam incorporados ao produto ou processo. Constitui, assim, a análise dos modos de falha no nível inferior e quais suas conseqüências no nível superior.
A análise da FMEA consiste em formar uma equipe para encontrar as funções do produto ou processo através de sessões de “brainstorming”, opinião de especialistas e outras técnicas, e, em seguida, avaliar os modos de falha potenciais, seus efeitos e suas causas. Na seqüência, por meio de pontuação de alguns critérios como severidade, ocorrência e detecção é gerado o índice N.P.R. – NÚMERO DE PRIORIDADE DO RISCO – para cada modo de falha. Os maiores riscos são priorizados e é recomendada uma ação para eliminar as causas evitando a ocorrência do modo de falha. Uma FMEA sem ações recomendadas não é completa e certamente não garantirá que o modo de falha não será instalado no produto ou processo. Essas ações podem envolver diferentes estratégias para se lidar com os riscos, como:
• Aceitar o risco da falha, quando o impacto é menor do que o custo de prevenção;
• Prevenir a falha;
• Minimizar a ocorrência das falhas ou de suas causas;
• Inserir mecanismos que aumentem a capacidade de detecção dessas falhas;
• Tomar ações para tornar mais efetivo os meios de controle das falhas;
• Adotar meios de redução do efeito da falha.

O fluxograma a seguir representa as interações entre os elementos da FMEA e os
processos do Gerenciamento de Projetos:


Segundo o formulário padrão de FMEA (IQA, 2001) o cabeçalho deve conter as seguintes informações:

Item – são todas as informações necessárias para identificar e monitorar o assunto da FMEA. É importante que a descrição dessas informações esteja de acordo com o sistema utilizado pela organização.
Responsável pelo Projeto – é o Gerente de Projeto, fabricante ou fornecedor dos produtos ou serviços, quando estes são adquiridos de terceiros.
Equipe – são os membros da equipe do projeto que tem autoridade para identificar e realizar tarefas para a solução de problemas futuros.
Número – é o número da FMEA. O seu objetivo é facilitar a rastreabilidade do documento.
Responsável pela FMEA – é a pessoa responsável pela elaboração e revisão da FMEA.
Data – São as datas inicial da FMEA e da sua última revisão.

Item / Função

As funções expressam obrigatoriamente o que o projeto, processo ou serviço deve fazer para satisfazer o cliente. Algumas perguntas podem ajudar na identificação dessas funções, são elas:
• O que deve ser feito para satisfazer os clientes?
• Para que serve este produto ou serviço?
• Por que é feito desta maneira?
• Por que tem que ser desta forma?
• Serve para mais alguma coisa?
Uma opção para este elemento é listar os itens do nível mais inferior (pacotes de trabalho) da EAP – ESTRUTURA ANALÍTICA DE PROJETO

Modo de Falha Potencial

É a forma pela qual a função deixa de atender aos requisitos do projeto, isto é, descreve como o projeto deixa de desempenhar a função definida no elemento anterior.
Para facilitar a descrição dos modos de falha, faz-se as seguintes perguntas:
• Que falha poderia ocorrer no cumprimento desta função?
• Como o produto ou serviço poderá falhar devido a esta função?
• Em produtos ou serviços similares já foi constatado algum modo de falha para esta função?
Se a equipe tiver dificuldade de identificar o modo de falha, basta considerar os 
modos de falha como expressões negativas da função.
Os modos de falha devem ser descritos em termos técnicos, e não como um sintoma evidenciado pelo cliente.
A definição de cliente para uma FMEA é normalmente o usuário final, entretanto o cliente pode também ser o responsável por uma operação subseqüente

Efeito(s) Potencial(is) da Falha

É a descrição das conseqüências do modo de falha, isto é, o que o cliente sofre quando o modo de falha, definido no elemento anterior, ocorre.
Sempre que possível, ao descrever os efeitos resultantes de um modo de falha, a descrição deve refletir a experiência dos clientes através dos sentidos, isso minimizará o risco de subestimar a severidade do efeito. Lembre-se que o cliente pode ser um cliente interno ou o cliente final. Essas experiências podem vir do marketing ou da assistência técnica e talvez
possam ser encontradas nos bancos de dados históricos de projetos semelhantes.
Geralmente os modos de falha apresentam uma cadeia de efeitos. Todos os efeitos devem ser escritos de forma seqüencial, desde a ocorrência da falha até o efeito final mais grave.

Severidade

A severidade aplica-se ao efeito e retratará qual será a gravidade das conseqüências da falha com relação a:
• Insatisfação do cliente;
• Custo para a organização;
• Imagem da organização;
• Riscos para a segurança pessoal do usuário.
A severidade é normalmente medida em uma escala de 1 a 10. O número 1 indica que o efeito não é serio aos olhos do cliente ou que o cliente talvez nem perceba o efeito e o número 10 reflete os piores efeitos e conseqüências resultantes do modo de falha.
As definições correspondentes aos números na escala de severidade que aparecem na Tabela abaixo e  servem como um guia para o desenvolvimento de uma escala
específica à organização. Uma redução do índice de severidade somente ocorre com a revisão do projeto.

Causa(s) Potencial(is) da Falha

São as deficiências do projeto que podem resultar no modo de falha em questão e devem ser listadas de forma a permitir ações preventivas para cada uma delas.
Busque e identifique todas as causas, independente da origem, que contribuem para o modo de falha. A origem das causas pode ser:
• O projeto;
• O fornecedor;
• O processo;
• O cliente;
• O ambiente;
• Qualquer local entre o projeto e o cliente.

Um mesmo modo de falha poderá ter causas distintas.

Ocorrência

A ocorrência é a freqüência com que o modo de falha ocorre durante o ciclo de vida do projeto.
Para facilitar a estimativa de ocorrência, faz-se as seguintes perguntas:
• O componente é novo ou semelhante a outro existente?
• Qual a experiência com componentes ou sistemas similares?
• Quanto significativas são as modificações feitas?
• O componente é completamente diferente aos existentes?
• Quais são as modificações feitas em componentes similares?
• Qual é o histórico de peças semelhantes em campo?

A ocorrência é estimada através de uma escala de 1 a 10. O número 1 indica uma chance remota do modo de falha ocorrer e o número 10 reflete a ocorrência certa do modo de falha.
Vários são os critérios de medição utilizados para definir a escala de ocorrência voce pode estabelecer um guia para o desenvolvimento de uma escala específica à organização/projeto.
Uma redução no índice de ocorrência somente ocorre quando uma ou mais das
causas do modo de falha são removidas ou controladas.

Controles Atuais

Os controles são as formas de prevenção e detecção de cada modo de falha, estes são estrategicamente colocados no processo de desenvolvimento do projeto, a fim de detectar possíveis problemas que foram previstos pela equipe e impedir que estes evoluam para as fases subseqüentes.
Existem dois tipos de controles do projeto a considerar:
• Prevenção – previne a ocorrência da causa ou do modo de falha;
• Detecção – detecta a causa ou o modo de falha, tanto por métodos analíticos ou físicos, antes do item ser liberado para a operação subseqüente.
Informações sobre os tipos de controles atualmente em vigor dentro da organização
ajudam no preenchimento desse elemento.

Detecção

A detecção é a estimativa da probabilidade de se detectar o modo de falha ou a causa, no ponto previsto e com a precisão e exatidão necessária, baseando-se nas formas de controle previstas.
Algumas perguntas ajudam na estimativa dos valores da escala de detecção, são
elas:
• A verificação do modo de falha ou causa é barata?
• O modo de falha ou causa é óbvio?
• A verificação do modo de falha ou causa é fácil?
• A verificação do modo de falha ou causa é conveniente?

A detecção é estimada através de uma escala de 1 a 10. O número 1 sugere que esse modo de falha ou suas causas certamente serão detectados antes de chegarem ao cliente ou a operação seguinte e o número 10 sugere que a forma mais provável de a organização tomar conhecimento do problema ocorre com a reclamação do cliente.
Como ocorre em outras escalas, a escala de detecção que aparece na Tabela 3
serve como um guia e deve ser ajustada, a fim de se adequar a cada organização.
Para alcançar um índice de detecção menor, o planejamento do controle do projeto
tem de ser melhorado. Crie sua escala !!

N.P.R. – Número de Prioridade do Risco

É o produto dos índices de severidade, ocorrência e detecção, conforme a fórmula

NPR = Severidade (N) x Ocorrencia(N) x Deteccao(N)

Onde:

NPR Número de prioridade do risco;
severidade N Índice de severidade do modo de falha;
ocorrência N Índice de ocorrência do modo de falha;
ecção Ndet Índice de detecção do modo de falha ou causa.
Dentro do escopo da FMEA este valor ficará entre 1 e 1000 e poderá ser usado para
priorizar as deficiências do projeto. 
Parece complicado, mas não é , complexo quando for utilizado da primeira vez, mas isto voce cria em planilha de cálculo rapidinho e, depois é manter....

Ações Recomendadas

São atividades capazes de prevenir os problemas potências, reduzir a severidade ou a conseqüência e aumentar a probabilidade de detecção desses problemas. O objetivo primário das ações recomendadas é reduzir os riscos e aumentar a satisfação do cliente através do aperfeiçoamento do projeto.
As ações devem ser primeiramente direcionadas às altas severidades (9 ou 10),
mesmo sendo o N.P.R de prioridade menor, pois nesses casos o efeito do modo de
falha coloca o usuário final em perigo.
Todas as ações recomendadas devem ser implementadas ou adequadamente
abordadas.

Responsável e Prazo

É a pessoa, equipe ou organização que executará a ação recomendada no elemento
anterior dentro do prazo estabelecido pela equipe do projeto.

Resultados da Ação

É uma breve descrição da ação realizada, com a data de sua efetivação e com os novos índices resultantes (severidade, ocorrência e detecção).

Acredito que voces deveriam se aprofundar mais nesta ferramenta quando se faz necessária na gestão de riscos porque ele deveria ser seguido em sua totalidade. De nada adianta durante a fase de planejamento do projeto fazer o planejamento do gerenciamento dos riscos, a identificação dos riscos, análise qualitativa e quantitativa, elaborar um plano de respostas aos riscos com a equipe do projeto e deixar este plano arquivado. É preciso que o processo de monitoramento e controle dos riscos também seja executado, pois é com ele que se obtém a garantia de que o planejamento está sendo realizado.Adotando  FMEA como Plano de Gerenciamento dos Riscos fornecemos um procedimento e garantimos que todos os processos do Gerenciamento dos Riscos, inclusive o de monitoramento e controle, sejam executados.

Gerenciando Clientes em Projetos - Experiências que não te contam...

Interessados em projetos, de modo prático e pragmático é qualquer pessoa afetada pelo projeto de qualquer forma  isto inclui inclusive sua...