Blog CMMI & MPS.BR

Muita gente acredita que “Código de Ética e de Conduta Profissional” seja uma das disciplinas do PMBOK. Estão enganados, pois não é! As nove disciplinas contidas no PMBOK são: gerenciamento do escopo, de riscos, de custos, da comunicação, dos recursos humanos, do tempo, da qualidade, de aquisições e gerenciamento da integração.

Em um primeiro momento, o fato do tema “Código de Ética e de Conduta Profissional” estar fora do PMBOK poderia causar entranheza ou algum tipo de desconforto aos leitores mal avisados, pois permite uma equivocada e precipitada conclusão de que o PMI estaria atribuindo baixa prioridade para assunto tão importante.Indiscutivelmente, a ética permeia todas as atividades de um gerente de projetos, para qualquer tipo de projeto, em qualquer uma das nove disciplinas mencionadas.

Na realidade, a ética está presente (ou deveria estar) no dia a dia de todas as pessoas, no exercício de nossas atividades profissionais ou pessoais, na escola, no trabalho, no clube, no trânsito, nos negócios, no cinema, na rua, enfim, a ética deveria ser o oxigênio levado a cada célula do organismo humano, dando-lhe vitalidade, saúde moral e direcionando as ações de empresários, políticos e cidadãos.

Retomando o tema de gerenciamento de projetos, em todas as nove áreas do conhecimento (disciplinas), a ética está presente. Por exemplo, no gerenciamento da comunicação, cabe ao gerente do projeto: elaborar/acompanhar o Plano de Comunicação do Projeto e distribuir a informação para os interessados no projeto. No entanto, é inerente à sua atuação nesta disciplina que ele seja ético, dizendo a verdade e sem postura de “omissão por conveniência” diante de situação desfavorável do projeto ou de seus resultados. De forma análoga, é responsabilidade do gerente de projeto no gerenciamento do escopo realizar a gestão dos requisitos do projeto, garantindo a entrega com qualidade nos prazos pactuados. Entretanto, do ponto de vista ético, o gerente deve deixar explícito, claro e documentado “o que o projeto faz e o que o projeto não faz”, evitando situações intencionalmente dúbias ou omissas. Há impasses em que muitos profissionais visando postergar a situação-problema alegam que “depois o cavalo fala…”.

Veja o post completo →

Pensando em projetos baseado nos relatórios de acompanhamento e no resultado final pode-se afirmar que existem apenas dois tipos de projetos:

1. Os que dão certo até dar errado e…
2. Os que dão errado até dar certo…

Parece uma visão muito pessimista, e apesar de você provavelmente não concordar… essa é uma visão tremendamente otimista (rsrs).

Todos que já trabalharam em projetos sabem que o ambiente de projeto é um ambiente complexo, por mais simples que seja o projeto existem dezenas de fatores que influenciam positivamente ou não cada elemento, e fazer com que todas essas variáveis estejam sempre de acordo não é um trabalho simples…

Mas voltando ao início, vamos analisar o primeiro caso:

Os que dão certo até dar errado
É aquele projeto onde tudo corre as mil maravilhas, mês a mês o percentual de completude do projeto evolui exatamente como previsto, sem nenhuma ocorrência, nenhum dos riscos se confirma, não existe mudança de escopo, não existe atrasos em atividades intermediárias… O Mundo perfeito, até… que o projeto chega nos seus 99% de conclusão…?Nesse momento, alguma coisa acontece, talvez um encosto, inveja ou olho gordo de alguém, mas o projeto trava nesse 99%, e nada faz com que ele ande…?Quando muito vai para 99,01, 99,02%…?Então se descobre que o projeto não teve apoio do Sponsor, que o usuário mudou 5 vezes o escopo, que o fornecedor atrasou, que um dos profissionais alocados saiu da empresa e não foi possível substituí-lo, que alguém dimensionou errado, enfim, o projeto em que deu tudo certo, dá errado.

Os que dão errado até dar certo
No segundo tipo de projeto, já no primeiro relatório, o Gerente de Projetos aponta que o usuário quer mudar o escopo, atividades atrasam e ações precisam ser tomadas para recuperar o tempo perdido, o fornecedor atrasa, como demonstra os reports diários de atraso do GP. Os riscos ocorrem, surgem novos, novas ações de resposta aos riscos são definidas, enfim, nada dá certo, até que se aproxima a data de entrega do projeto e, MILAGROSAMENTE, o projeto acontece, e o projeto dá certo…

Veja o post completo →

O objetivo deste post é apresentar os principais elementos que um bom plano de projeto deve ter. Não existe um modelo padrão pois existem tantas variáveis que é praticamente impossível definir um plano de projetos que atenda todo mundo. Vai depende muito mais do cenário e projeto. Mas aqui vão algumas dicas que lhe ajudarão a ficar aderente ao CMMI, MPS.Br e PMI, mas tenha em mente que este não deve ser seu principal objetivo (ficar aderente) e sim, fazer um bom planejamento para seu projeto.

Um bom plano de projeto deve…

… ter seus objetivos definidos
Infelizmente muitos gerentes de projetos falham neste ponto, mas voce deve ter muito claro quais são os objetivos do projeto, tanto para seu cliente quando para você. Para seu cliente a data de entrada do sistema pode ser o principal objetivo do projeto, já você, pode definir entregar com uma semana de antecedência (para reduzir os riscos), reduzir o custo em 10% e por ai vai. O fato é que todos os objetivos devem ser documentados. Outro fator importante é coletar as expectativas de todas as partes interessadas e se necessário,

… ter o escopo definido
Em linhas gerais, o escopo nada mais é do que será feito, então, seu plano de projeto dever detalhado o que será feito em seu projeto. Todas as tarefas e produtos de trabalho fazem parte da definição do escopo. Neste momento você deve definir a WBS do projeto.

… ter estimativas
Você deve ter estimativas de tudo. Estimativas de tamanho, tempo, custos, prazo, recursos, enfim, estimativas que lhe ajudem a fazer o projeto. Como exemplo, o esforço foi estimado com base em uma técnica de dimensionamento como APF ou UCP (ou alguma outra), com este esforço você calculou prazo e consequentemente custo, logo, seu projeto deve seguir estas estimativas, pois caso contrário, o mesmo afundará. Documente sempre qual foi o modelo utilizado para estimativas. Veja mais sobre tamanho em Tamanho importa?

… ter a definição do ciclo de vida do projeto
O ciclo de vida do seu projeto define as fases e atividades padrão de um projeto. Um projeto normalmente tem fases como “Gerenciamento”, “Especificação funcional”, “User Interface”, “Especificação técnica”, “Desenvolvimento”, “Testes”, “Homologação” e “Implantação”. Mas, isto dependerá de projeto a projeto.

… ter um cronograma
Não há muito segredo no desenvolvimento de um cronograma. Ele deve basicamente ter suas fases e atividades, datas, recursos envolvidos, responsáveis, dependências, milestones, esforço, custo, e percentual de completude. Isto é o básico, praticamente todo cronograma tem estes elementos, mas a complexidade do seu cronograma dependerá mais da sua necessidade (seu projeto) do que de um template padrão. Procure sempre manter seu cronograma atualizado e sempre usa-lo em seus eventos de acompanhamento.

Veja o post completo →

Esta área de processo é muito mal compreendida em TI (e mal utilizada). A maioria das empresas define como risco um percentual a mais para se inflar o custo de um projeto como por exemplo:

• Cliente novo: 10%
• Falta de pessoal disponível: 5%
• Linguagem nova: 5%
• Ambiente “encardido”: 10%

E por ai vai… Com isso, se o projeto inicialmente custava R$ 50.000,00, agora ele custará 30% a mais, ou seja, R$ 65.000,00.

Esta é uma análise equivocada do que é riscos em projeto, e consequentemente não tratou o problema (risco), apenas criou um fundo para tentar cobrir um possível prejuizo.

Esta análise equivocada é mais comum do que parece, constantemente vejo casos assim em empresas que presto consultoria, mas isso acontece porque muitos acham que gerenciamento de riscos é um bixo de sete cabeças, já vi muita gente falar “isso não serve pra nada” e até mesmo “Isso é teoria, na vida real ninguém usa”.

Então, vamos “descomplicar” este assunto. Primeiramente, Gerenciamento de riscos é mais fácil do que parece e é muito provável que você faça isso no seu dia-a-dia de forma tão natural que nem perceba. Vamos a um exemplo:

Você vai em uma concessionária VW e compra um Fox zerinho. A entrada veio de suas economias de dois anos e o restante foi financiado em 48 vezes.

Agora… onde estão os riscos com esta nova aquisição? Vejamos alguns:

• Seu Fox pode ser roubado
• Alguém pode bater nele
• Você pode sofrer um acidente
• Você pode tomar uma multa
• E várias outras coisas

Estes são alguns dos riscos e obviamente você precisa tratá-los e há várias formas para isso como contingência, mitigação, transferência e outros.

Vamos tratar este caso juntos. Se o seu Fox for roubado, além de ficar sem carro você ainda terá que pagar as prestações, então, para isso você precisa de uma contingência, ou seja, um Plano B. Você contrata um seguro para seu carro. Com isso você transferiu o risco para seguradora, e esta por sua vez, coloca várias cláusulas no contrato para você não abusar ou agir de má fé.

Veja o post completo →

OT – Treinamento organizacional

50. Tenha um mapa de treinamentos necessários para cada função
51. Defina claramente quais os treinamentos de responsabilidade da empresa e quais são os do projeto
52. Envolva a área de treinamento no planejamento do projeto
53. Identifique quais são os treinamentos necessários para atender os objetivos estratégicos da empresa
54. Mantenha um programa de treinamento contínuo
55. Colete informações de desempenho dos treinamentos
56. Verifique se após os treinamentos houve melhora de desempenho nas pessoas
57. Tenha uma descrição de responsabilidades e autoridades de cada função
58. Planeje o investimento com treinamentos e periodicamente verifique os benefícios
59. Armazene os dados de treinamentos

PI – Integração de produto

60. Identifique as necessidades de integração entre produtos e componentes
61. Planeje como será a sequência de integração
62. Crie critérios para garantir que os produtos estão prontos para serem integrados
63. Tenha métodos alternativos de integração e selecione o melhor (se possível com DAR)
64. Armazene informações sobre o processo de decisão sobre integrações
65. Tenha guias ou processos de como as atividades de integração devem ser realizadas
66. Verifique a compatibilidade entre as interfaces
67. Documente os ajustes necessários nas interfaces
68. Crie mecanismos que garantam que o produto final contem as versões corretas dos códigos e componentes

RD – Desenvolvimento de requisitos

69. Identifique as necessidades do projeto
70. Identifique as expectativas que os envolvidos tem com o projeto
71. Tenha guias que auxiliem o desenvolvimento de requisitos
72. Traduza os requisitos de negócio e necessidades em requisitos técnicos
73. Verifique antes da validação com cliente
74. Defina critérios que liberem os produtos para validação com cliente
75. Assegure o entendimento correto dos requisitos – valide formalmente com o cliente
76. Faça o mapeamento dos requisitos com funções, códigos, componentes, aquisições, etc.

Veja o post completo →

1. Monitore diariamente o desempenho do projeto
Monitore diariamente elementos como custo, qualidade e atendimento a prazo. Você deve documentar no plano de projetos qual a qualidade esperada e variação de custo e prazo. Considere a utilização de EVM para monitorar o custo e prazo, além disso, tome ações sempre que o desempenho sair dos seus limites de controle.

2. Gerencie o escopo
Verifique quais são as reais expectativas do cliente e em casos de divergência negocie com base nos dados que você tem (uma proposta comercial com o escopo ajuda muito).
Ambos devem ter ciência do que foi comprado e o que será feito. Não há problema algum em alterar o escopo, porém deve ficar claro o impacto de alterações (para mais ou para menos). Formalize sempre o que será feito e formalize também toda mudança.

3. Tenha auditorias de qualidade periódicas e independentes em seus projetos
Uma auditoria independente (PPQA por exemplo) ajuda muito a saber se o projeto esta bem sob a óptica da empresa. Utilize isto para corrigir possíveis problemas em casa e não no seu cliente.

4. Faça reuniões de acompanhamento periódicas
O PMI fala muito sobre isso. É muito importante fazer eventos de acompanhamento tanto interno (com sua equipe) quanto com seu cliente (apresentando o desempenho). Documente sempre os eventos de acompanhamento e utilize esta documentação para na próxima reunião.

5. Mantenha a equipe motivada
Motivação é um dos pontos chave de todo projeto (em breve escreveremos mais sobre isso). Uma equipe motivada produz produtos de mais qualidade e em tempos menores. Apple e Pixar são grandes exemplos de equipes empresas motivadas. Bonifique o desempenho acima do previsto. Diversos problemas deixarão de ocorrer pelo simples fato de ter uma equipe motivada.

6. Gerencie os riscos do projeto
Durante todo o projeto você gerencia riscos, pode-se até dizer que o gerenciamento de projetos é na verdade gerenciamento de riscos, desta forma, identifique todos os possíveis riscos e defina planos para gerenciamento destes riscos. Sempre que possível tenha uma contingência para os casos onde “algo deu errado”

Veja o post completo →

DAR – Análise de decisão e resolução

1. Crie um guia para orientar as tomadas de decisões formais
2. Crie critérios que definam quando um processo de decisão formal deve ser realizado
3. Defina critérios para a seleção de alternativas
4. Identifique as soluções alternativas
5. Analise o que normalmente é feito em processos similares
6. Defina claramente o método que será utilizado para análise das alternativas
7. Nunca, jamais se esqueça de analisar as alternativas e documentar esta análise
8. Analise os riscos associados a escolha ou não de uma solução
9. Documente todo o processo de decisão formal
10. Mantenha os dados em gestão de conhecimento para consulta posterior

IPM – Gerenciamento integrado de projeto

11. Tenha uma base de processos
12. Mantenha uma base de melhores documentos, lições aprendidas, modelos, templates e outros
13. Mantenha um plano integrado de trabalho que contemple as atividades de outros grupos bem como previsão de alocação
14. Crie planos que definam como conflitos serão tratados
15. Defina critérios de entrada e saída para as atividades
16. Utilize os planos integrados para o gerenciamento do projeto (um plano de gerenciamento de projeto pode lhe ajudar bastante)
17. Periodicamente atualize a base de conhecimento da organização
18. Mantenha um canal para entrada de sugestões
19. Periodicamente avalie as sugestões e forneça feedback de como estão as sugestões
20. Defina o envolvimento dos stakeholders e comunique-os de suas responsabilidades
21. Identifique e gerencie as dependências e compromissos do projeto
22. Documente ações preventivas e/ou corretivas quando necessário

OPD – Definição do processo organizacional

23. Crie padrões para definição de processos
24. Documente os processos
25. Elabore uma matriz contendo os processos, produtos, atividades e responsabilidades
26. Documente o relacionamento entre os processos e produtos
27. Defina SDLC’s para os principais produtos e serviços
28. Defina critérios para tailoring dos processos quando necessário
29. Documente os processos tailoring dos projetos (quando necessário)
30. Mantenha uma base de medições
31. Periodicamente verifique se há necessidades de ajustes nos processos
32. Estabeleça padrões de infra-estrutura e ativos de processo de acordo com o papel
33. Realize revisão entre pares sempre que houver alterações nos processos
Veja o post completo →

Recursos computacionais críticos ou RCCs são coisas tipicamente esquecidas nos projetos e normalmente sua ausência tras grande impacto.

Podemos definir (mas não somente) como RCCs itens atípicos de Hardware. Imagine que você esta fazendo um sistema que mostrará o horário dos voos em aeroportos e para isto utilizará um display de plasma de 72 polegadas.

Este display de plasma é seu RCC neste projeto.

Se você não tiver um para testar seu sistema, talvez você terá que fazer vários ajustes quando for implantar no display de verdade (e acredite, você terá).

Parece bobeira, mas muitos menosprezam o impacto que a ausência de um RCC pode trazer, por isso, sempre verifique se seu projeto tem algum RCC e gerencie a aquisição do mesmo bem como o risco de se não ter.