Como encontar “o que deu errado?” em seu projeto

Deixe um comentário

Indicado por Leona Charles do TOC Intelligence Group no LinkedIn

Looking for Root Cause in All the Wrong Places

  • August 24th, 2010 5:06 am ET

Solution Boxes

Photo: Salvatore Vuono/freedigitalphotos.net

Across the country on any given day, someone in management is uttering the phrase ‘where did it all go wrong?’ Conventional wisdom says you look at your people and then your process and you work backward to spot dependant variables and points of failure. I sit on the other side of the bench. As a Process Improvement Consultant, certain situations have left me in awe of how little decision makers rely on common sense. If you really want to find the root cause, stick to these guidelines.


Don’t Just Find the Points of Failure, Solve Them
.
Finding the points of failure doesn’t mean you know all that you need to and finding them shouldn’t mean someone is getting fired. Points of failure should alert you to parts of your process that are flawed or underperforming. Once the point of failure has been identified, you need to find out what made it a failure point. Is the process too complicated? Does your staff understand the step? How does the failure affect your end product? Once you have answered these questions, you can begin the process analysis of dependant variables and points of failure.
Know Where You Are Going

Many processes fail or underperform because the companies or the people implementing them don’t understand the program objective. If your goal is to produce the best product possible, why focus on cost beyond what is reasonable? By the same token, if your goal is to produce the cheapest version of your product then quality issues are the second runner up. When running your process you have to be sure that your end goal matches your process. Be clear about your process expectations with every activity.

Set Your Standards in the Beginning


Before your process starts, define clearly and succinctly what constitutes quality and failure. With a clear picture, you minimize the guesswork enabling you to work from preventive posture instead of reactionary. The quality of your process is set in the beginning, working towards the quality of your end product. Setting standards also creates working guidelines for you staff and allows them to set reasonable expectations, the clearer your staff the better your process.
Allow Failure


I know this sounds counterproductive, but quality comes from failure. A business culture where it is okay to fail makes your product or service better. When you go back to the drawing board, you go back with lessons learned and that makes your company better in the long run. It’s easier to benchmark when you know that an idea has no practical application, it’s easier to improve when you know where to start.

Improvement is a tricky business and no technique is one size fits all; the trick is to find one that works for your company. Remember continuous improvement is a journey and every step is meaningful. To be better, you have to think better. The best place to start is common sense.

Game em Flash ensina processos do PMBOK

Deixe um comentário

Indicação de Juliano Messaggi.

Puzzle em FLASH para ajudar no aprendizado dos processos do PMBOK. Excelente para os estudos ao PMP.

http://www.arkatay.com/dev

Tutorial sobre APF (FPA) Análise de Ponto de Função

Deixe um comentário

A análise de pontos de função tem como objetivo medir um software criado afim de estimar custo ou dificuldade baseada nas quantidades de vezes que determinadas funções são requisitadas pelo software independente da tecnologia utilizada.

Apesar de parecer meio “estranho” para alguns temos sempre que estar atentos aos diferentes approachs que podemos dar a cada projeto e os objetivos de cada business.

Segue um bom tutorial sobre o assunto: An introduction (tutorial) to Function Point Analysis.

Podcasts descontraídos ensinam GPs!

Deixe um comentário

Em minhas andanças pelo linkedin encontrei o grupo SGP, muito bom e inusitado sobre o ensino das práticas de GP!!

Quando as coisas estão apertadas, nada melhor do que ouvir um podcast informativo. Confiram: SGP – Sou Gerente de Projetos – Podcast – Informações sobre Gerenciamento de Projetos.

No olho do furacão I: A Cultura Sul-Coreana

1 Comentário

Inicio neste blog uma sequencia de tentativas de entendimento de como empresas gigantes e altamente lucrativas sul-coreanas estão conseguindo liderar mundialmente (em vários segmentos) se para alguns de nós que estamos vendo “dentro do olho do furacão”, parece mais uma empresa que irá se desmantelar em 1 ou 2 anos.

Tudo começou quando eu estava vindo pela marginal Pinheiros hoje (11/08), curtindo nosso habitual trânsito matinal em mais um dia de trabalho, e simplesmente fiquei imaginando como a minha vida como gerente de projeto estava uma zona atualmente, usei então os 5 WHYs do Lean para tentar entender isso:

  1. WHY está uma zona? Resp: não consigo aplicar as ferramentas e boas práticas de gestão de forma consciente.
  2. WHY não consegue aplicar? Resp: minha empresa é confusa e não tem posicionamento.
  3. WHY não se posiciona? Resp: meu cliente age de acordo com suas próprias vontades sem se preocupar com processos e estruturas.
  4. WHY não se preocupa? Resp: aparentemente as nossas estruturas são diferentes das deles e eles não nos ouve.
  5. WHY não nos ouve? Resp: eles tem outra cultura, SÃO SUL-COREANOS.

Não sei se só havia este caminho na minha análise, mas me levou a algum lugar sólido. Nossa diferença cultural: brasileiros e coreanos.

Então resolvi investigar e logo cedo liguei para um colega brasileiro que trabalha tb em uma emprea sul-coreana e começamos a delinear algumas idéias a respeito disso. Ele me recomendou um blog muito legal do Henrique Teixeira, um caboclo de Minas que está na Coréia do Sul e vem relatando coisas interessantíssimas sobre nossas diferenças culturais.

Bom segue um texto inicial (recomendado pelo colega Juliano Messaggi) para este começo de entendimento: http://deprosanacoreia.blogspot.com/2009/09/uma-geral-no-racismo-coreano.html

Simulado PMP ON-LINE Gratuito 2010

2 Comentários

Estou caminhando para a certificação PMP e tenho descoberto alguns simulados na rede, este é do PMStudy, simulado ON-LINE, igualzinho ao que (creio) todos faremos em breve…
Ele é gratuito, porém com validade e licenças limitadas, sem dúvida é o mais legal que já fiz… http://www.pmstudy.com/enroll.asp#PMP

Pelo menos no simulado eu aprovei, hhehehe!! Agora é marcar o exame…. estou preenchendo a papelada. Quem quiser trocar uma idéia é só me dar um toque.

Abs,

Danilo

Acho que mudaria de PDCA para PTDCA

Deixe um comentário

Estava estudando um pouco de estratégia e percebi que o PDCA é meio pobretão.

Acho que é muito mais correto dizer que o ciclo é PTDCA, uma vez que comunicação É a chave para toda e qualquer gestão (ou para tudo…?!?). Fiquei então assim:

PLAN-TALK-DO-CHECK-ACT

  1. PLAN (Planeje ou re-planeje)
  2. TALK (Comunique, fale, divulgue, explique, receba idéias)
  3. DO (Faça, implemente, ponha pra rodar)
  4. CHECK (Verifique, avalie, meça, calcule, veja se esta tudo certo, teste)
  5. ACT (aja nos problemas, apresente soluções, inove)

Nada de novo só o óbvio, para fechar a semana sempre lembrando disso!!

The Lazy Project Manager eBook – GRATIS!!

Deixe um comentário

Visitem e baixem o e-book gratuitamente… válido somente por 7 dias!!

The Lazy Project Manager eBook.

Dicas e Simulados do Exame PMP

Deixe um comentário

Juntei a um tempo atrás este material espalhado na web e que está sendo muito bom para meus estudos. São 5 dicas genéricas (abaixo) e depois deixei disponível o seguinte material em pdf:

    5 Dicas para fazer o PMP

    1.Ler o material da Rita Mulcahy (ou outro) pelo menos 3 vezes (pelo menos 1 vez acompanhado do PMBOK). Utilizar pelo menos uma vez um mind mapping para tomar notas será de grande valia. Nas áreas de Escopo, Qualidade e Aquisições haverão muitas questões sobre entradas/ferramentas/saídas; Em risco a ordem dos eventos (fluxo do processo) é importante; Então muita atenção ao material lido.

    2.Estude em pequenos e frequentes intervalos. Quando se aproximar da data do exame, faça planos de quanto e onde vc irá ler os trechos do material a ser estudado. Só de executar este plano sua autoconfiança irá crescer.

    3.Não gaste horas, tarde da noite, estudando dias antes do exame. Isto não é como as provas do colégio. Este teste medirá seu entendimento conceitual sobre gerenciamento de projetos baseado em sua experiência. Vc deverá mapear sua experiência nos termos presentes no PMBOK e é só isso!

    4.Tire algumas folgas sem culpa e durante o exame fique em alerta. Deixe de lado café, chá, cigarro e alcool perto de um mês antes do exame para que a agilidade de sua mente aumente.

    5.Faça simulados entre as leituras do PMBOK e materiais adicionais. Reveja os resultados no mesmo dia e identifique onde vc errou. Fazer “n” simulados antes do exame não é o objetivo, apenas mapeie as áreas onde seu pensamento tem comumente desviado dos conceitos do PMI e estude com afinco. Alinhar suas experiências as práticas do PMI é a chave.

    Acerte na coleta de Requisitos (com uma idéia vinda do Scrum)

    Deixe um comentário

    Coleta de requisitos… assunto que sempre vigente nas rodas de samba dos gerentes de projetos e clientes de todo mundo! Saiba que 60 a 80% dos projetos estão diretamente ligados a falhas no levantamento, análise e gerenciamento dos requisitos (Fonte: Meta Group).

    Uma boa prática que tenho adotado em meus projetos vem do Scrum, chama-se “User Stories”, mesmo quando não utilizo de técnicas ágeis integralmente, sempre trago esta parte de coleta de requisitos comigo debaixo do braço.

    User Stories, traduzindo ao pé da letra já nos da uma boa idéia do que seria: “Estórias do Usuário”. É uma modo de coleta de requisitos onde escreve-se de forma simples e concisa, utilizando o vocabulário do cliente o que ele quer, com o máximo possível de detalhes. O sujeito, foco das estórias são sempre o usuário/cliente, sendo completamente proibido mencionar termos técnicos ou rebuscados neste momento

    Duas dicas disfarçam acrônimos interessantes (em inglês) para as user stories:

    INVEST in Good Stories

    Independent, Negotiable, Valuable, Estimable, Small, Testable

    • Cada User Storie deve ser, o máximo possível, independente de outras histórias.
    • Aquilo que ela descreve deve ser perfeitamente negociável entre o fornecedor e o cliente (de fato, ela deve poder ser traduzida, posteriormente, em um plano de trabalho ou contrato de serviços).
    • O cliente deve perceber o valor da User Story tanto como apoio à compreensão na construção da solução quanto na percepção do resultado de seu investimento na mesma.
    • E cada história deve ser pequena e testável.

    SMART Tasks

    Specific, Measurable, Achievable, Relevant, Time-boxed

    • Cada tarefa deve ser específica, contida em si, bem definida e também independente.
    • Deve poder ser medida para que seu custo possa ser efetivamente avaliado.
    • Obviamente, temos que definir tarefas que possam ser realizadas.
    • Deve ser relevante à estória e, se na definição das tarefas, uma delas parecer não estar relacionada com a estória, então ela ou a estória devem ser revistas.
    • Deve ter um período de tempo definido.

    Algumas dicas de como produzir boas User Stories (extraídas do blog de David Churchville)

    1. Make them customer-focused. The easiest way to do this is to have the customer write them. If this isn’t practical, then you’ll have to role-play. An example of a developer-focused story is “Add clustered index to the Orders table.” This doesn’t mean much to most customers, and a real customer (unless they are a DBA), would probably never write this. Instead, something like “Improve Order reporting performance”, captures the same information, but is understandable to everyone on the team.

    2. Make them elevator-friendly. A good story should be something you could explain on an elevator in 30 seconds or so to a team member. Don’t write a novel. Remember, this is just a placeholder for more detailed conversations, not a specification or requirements document.

    3. Make them the right size. Not too big, and not too small, just like Goldilocks said when she visited a tough bear hangout. For me, the right size is usually under 40 ideal hours (1 ideal week) of estimated effort. Small stories aren’t usually a problem, but if they get to be under an hour or so, you probably want to batch them up. Defects are usually good candidates for batching into a single story, as long as they are small and easy to implement.

    4. Make them testable. An untestable story might be something like “Make the order screen easy to use.” It sounds nice, but no one really knows what this means, or how to objectively verify it. A better wording choice might be: “A novice user be able to load, enter information, and submit an order within 5 minutes.” Hmmm…still seems a little questionable, but I can probably write a test like “Given a sample group of 10, 8 of these users should be able to complete an order for a book in 5 minutes.”

    Um exemplo bem simples feito pela Universidade Estadual da Carolina do Norte, descreve o projeto de desenvolvimento de uma máquina de café.

    Um livro altamente recomendado é o do Mike Cohn: User Stories Applied.

    Texto adaptado do blog Scrum – User Stories | Brod Tecnologia.


    Entradas mais Antigas

    Seguir

    Obtenha todo post novo entregue na sua caixa de entrada.