Posts Tagged ‘ pmi

Analisando o custo x benefício em um projeto 31 August 2009 as 3:22 am de Washington Souza

Uma das principais responsabilidades de um gerente de projetos é zelar pelo custo do projeto e usar este dinheiro da melhor forma possível (Leia o PMI para mais detalhes).

Apesar disto ser (vamos dizer) óbvio, não são muitos os gerentes que fazem uma boa gestão do custo, e, durante o planejamento do projeto o gerente do projeto deve analisar tudo o que deve ser feito e fazer uma análise de custo x benefício .

Se você tem 10.000 para fazer uma determinada coisa, e existe um “componente” que faz exatamente o que você quer por menos da metade do preço, porque não adquiri-lo? Bom, é muito provável que você já deva ter presenciado uma situação assim, e é mais provável ainda que a decisão tenha sido de “fazer” o requisito, perdendo assim uma excelente oportunidade para economizar.

Outro caso é: Em um sistema onde você o usuário se cadastra e escolhe seu estado a pergunta é: Será desenvolvido uma tela de manutenção de estados?

Cenário 1: Sim, o cliente precisa atualizar a lista de estados sempre que precisar – Custo: R$ 1.000,00 (referente à 20 horas de trabalho)

Cenário 2: Não, é uma tabela que raramente muda, o custo não justifica o benefício – Custo: R$ 0,00

É um caso simples, mas neste caso simples você já economizou um montante do seu custo. Claro que existirão casos onde estes desenvolvimentos serão necessários, todavia serão minoria e mesmo nestas minorias, provavelmente a contratação de um serviço (como o de CEP dos correios) saia mais em conta.

Uma dica: Pratique esta análise durante o planejamento. Provavelmente você terá boas surpresas.

+ Top 10 dicas para um bom gerenciamento de projetos Por Washington Souza 15 May 2009 as 11:56 pm Nenhum comentário

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 →

+ CMMI: Ajuda ou atrapalha? Por Washington Souza 08 May 2009 as 10:43 pm 1 comentário

Olá pessoal, já a um bom tempo estou querendo escrever sobre isso, mas o texto de João Werther Filho da Desenvolva foi certeiro. Ele explica se o CMMI ajuda ou atrapalha de um jeito muito simples e fácil.

CMMI: Ajuda ou atrapalha?

De uma forma bem sucinta, o CMMI (Capability Maturity Model Integration – Modelo Integrado de Capacitação e Maturidade) é um modelo bastante aceito e de alta credibilidade no que se refere a medir a maturidade do processo de uma organização. Quanto mais madura o seu processo, maior a qualidade do produto final oriundo do processo. Pelo menos é o que pensa o SEI (Software Engineering Institute), órgão da Universidade Carnegie Mellon, patrocinado pelo Departamento de Defesa dos Estados Unidos, e responsável pela elaboração e manutenção do modelo CMMI.

yes or noO SEI acredita que a maturação do processo da organização é diretamente proporcional à qualidade do produto final obtido, mas não é só isso. O SEI acredita que o modelo CMMI também facilita para que a organização consiga elaborar o produto final do seu projeto com meios para que o custo, esforço real, e qualquer outra variável relevante ao processo, não se desvie muito do estimado e que tenha a melhor produtividade possível. E tudo isso aplicando as melhores práticas existentes dos processos. As melhores práticas de gerenciamento de projetos, por exemplo, que estão publicadas hoje no PMBoK (Project Management Body of Knowledge – Corpo de Conhecimento da Gerência de Projetos), estão, de certa forma, descritas no modelo. Em outro exemplo mais aplicável para nossa área, ou seja, no caso de processos de desenvolvimento de software, estão contidas no modelo as melhores práticas da engenharia de software.

Para muitos, um processo de desenvolvimento de software baseado no CMMI é muito burocrático e o custo do produto final termina aumentando. Afinal, segundo eles, nem todas as práticas são realmente necessárias na maioria dos casos e muito trabalho poderia ser evitado, principalmente em projetos pequenos. Frases como “O CMMI engessa o processo”, “O custo de desenvolvimento fica alto devido ao CMMI”, “O CMMI vai contra um processo ágil” são emitidas freqüentemente por profissionais que seguem essa linha de pensamento. Para eles, a qualidade gerada pelo CMMI possui um preço muito alto a se pagar e não agrega muito valor à organização.

Veja o post completo →

+ O que é EVM – Earned Value Management Por Washington Souza 20 April 2009 as 1:50 am 2 comentários

Um bom método para monitoramento do desempenho de projetos é a técnica de Valor Agregado (EVM – Earned Value Management). Apesar de muito utilizada em países como os EUA, aqui no Brasil esta técnica ainda é pouco utilizada e um de seus maiores disseminadores é o PMI. Aliás, tenha em mente que além de gerenciar melhor seus projetos, você estará atendendo várias práticas do CMMI e algumas necessidades do Six Sigma.

Com EVM podemos ver coisas como:
- Como o projeto esta?
- Como ele deveria estar?
- Os gastos do projeto estão adequados ao trabalho realizado?
- O projeto será entregue dentro do prazo e custo?
- Qual a previsão de desvio de prazo e custo?

Exemplo simples de EVM

Entendendo as características básicas
Você faz o planejamento de um projeto que tem 10 dias e custo de 100.000.
A primeira coisa que você terá que fazer aqui é calcular o custo diário de seu projeto. Lembre-se que para isto você deverá ter um WBS bem detalhado e que reflita a situação real de seu projeto.
Você monta o WBS e obtém um planejamento como esse:Grafico com o custo planejado

Sempre recomendo transformar os números em gráficos pois fica mais fácil de se entender e reduz sensivelmente interpretações erradas.

Seu projeto esta em andamento e você coleta o custo do projeto todo dia. Seu projeto esta no sexto dia e quando você olha para o gráfico você acredita que o projeto esta ruim, pois o planejado para o dia é 40.000 e você já gastou 50.000.

Você apresenta este gráfico na reunião de acompanhamento semanal de projetos.
Grafico com o custo planejado de um projeto e o realizado
Veja o post completo →

+ Entendendo o gerenciamento de mudanças Por Washington Souza 14 April 2009 as 3:37 pm 6 comentários

Pesquisas apontam que pelo menos metade dos fracassos em projetos de TI vem da falta de gerenciamento de escopo.

Simplificando, o escopo do projeto, nada mais é do que o que foi combinado fazer.

Vamos à uma analogia: Preciso trocar os pneus do meu carro. Faço um levantamento dos produtos e serviços necessários e verifico que precisarei de:
- Quatro pneus [Produto]
- Troca dos mesmos [Serviço]
- Alinhamento [Serviço]
- Balanceamento [Serviço]

Bom, este é o escopo deste meu projeto “Trocar Pneu” e devo fazer uma gestão efetiva deste escopo, para não gastar mais que o previsto.

Vou na loja, faço o pedido e aguardo. Após meia hora o vendedor (que obviamente quer vender) me fala que seria bom eu trocar os amortecedores também porque estão ruins. Vamos parar um pouco neste ponto.

Trocar os amortecedores tem custo e o vendedor vai cobrar com certeza. Esta troca esta fora do meu escopo inicial e devo decidir se mudarei o escopo ou não.

Reparem que quem decide sou eu, só que esta decisão traz impacto (aumento do custo). Será que vai adiantar alguma coisa se eu chegar ao vendedor e “espernear” falando que isto estava “sub-entendido” na troca e por isso não vou pagar? Com certeza não. Eu ficaria muito feliz se ele fizesse isto de graça, mas isto não vai acontecer pois tem custo pra ele.

Voltando, decido por não trocar pois esta fora do meu escopo inicial e isto ultrapassará o valor que eu tinha previsto.

Se coloquem agora no lugar do vendedor (que é o nosso!) e simulem a mesma situação. Vocês dariam os amortecedores ao cliente?

É isto que não se pode fazer (dar algo não combinado), temos sim é que cumprir o escopo previsto em nossos projetos e sempre posicionar o cliente de possíveis necessidades de mudanças.
Mas lembrando, o escopo não muda, a não ser que alguém permita.
O Gerente do projeto deve sempre ser firme e demonstrar os impactos (esforço, custo, prazo, etc) e nunca permitir o aumento sem que o cliente concorde com os impactos (formalmente). Comunicação é primordial.

Você deve tratar os custos (estimativas em geral) dos projetos como se este dinheiro fosse sair do seu próprio bolso.

Em tempo: Alguns pontos ajudam muito a “definir o escopo” como:
- Uma proposta comercial bem elaborada;
- Deixar claro o que será feito e o que será entregue (tudo);
- Deixar claro o que não será feito;
- Deixar claro suas responsabilidades e as do seu cliente;
- Estimar com uma técnica segura sempre que possível – recomendo APF (melhora significativamente a acertividade);
- Fazer um bom planejamento e gerenciar de verdade o projeto;

Fazendo isto sempre em seus projetos, além de reduzir considerávelmente suas dores de cabeça com o projeto você também estará atendendo boa parte da parte de engenharia do CMMI

Veja o post completo →

+ Plano de gerenciamento de projeto Por Washington Souza 01 April 2009 as 11:35 pm 1 comentário

Constantemente quando falamos sobre o Plano de Gerenciamento de Projetos (PGP) as pessoas indagam com: “Mas não é a mesma coisa que o plano de projeto”. Bom… a resposta é não. Vamos analisar o PGP em um cenário prático.

O plano de gerenciamento do projeto ajuda a ter ações pró-ativasO PGP tem por principal objetivo definir as ações que serão tomadas de acordo com o desempenho de diversos fatores do projeto, como:

Você esta fazendo um projeto onde o prazo é o ponto crítico. Este projeto é dividido em 3 fases com 10 dias cada e você enfrenta os seguintes problemas em cada fase:
Fase 1: Projeto atrasado em 3 dias, pois metade da equipe é formada de estagiários.
Fase 2: Projeto atrasado em 3 dias por indisponibilidade do cliente em validar os produtos.
Fase 3: Projeto atrasado em 3 dias por que o ambiente de validação não esta pronto.

Na maioria das empresas isto é encarado como causas normais de um projeto e acaba-se assumindo estes custos.

Com um PGP você deve prever os tipos de problemas e definir quais ações você tomará quando gatilhos forem acionados (Gerenciamento preventivo – CMMI3), imaginando que você montou o PGP deste projeto teríamos o seguinte cenário.

Fase 1: Seu projeto esta atrasado em 3 dias (você esta no 6º), mas isto não é problema, pois seu PGP diz que se isto acontecer você deve substituir os estagiários por planos e seu projeto terminará no prazo.
Fase 2: Falta um dia para acabar a fase e seu cliente nem começou a validar você pega o PGP e nele esta definido que se isto acontecer quem validará é o Sponsor ou haverá repasse de custos (e seu cliente já aprovou isto).
Fase 3: Você esta no 7º dia e o cliente informa que precisará de mais 3 dias para deixar o ambiente pronto. O seu PGP diz que se houver indisponibilidade do ambiente a validação será realizada com no seu ambiente de desenvolvimento (o cliente aprovou).

Enfim, note que antes do inicio do projeto houve uma análise minuciosa de possíveis problemas e ações que deveriam ser tomadas. Para apoio você também buscou as aprovações formais de cada uma destas ações. Ou seja, você foi pró-ativo (CMMI 3).

Os casos apresentados aqui são muito simples visto que seu objetivo é apenas de apresentar os benefícios do PGP, em um projeto real, seu PGP deve ser bem estruturado e você deve ter ações para os problemas mais comuns ou mais prováveis.

O PGP é um instrumento que ajuda muito no gerenciamento de projetos, considere sua implementação se você esta buscando o nível 3 de maturidade do CMMI.

Veja o post completo →

+ Acompanhar ou gerenciar? Por Washington Souza 03 September 2008 as 12:14 am Nenhum comentário

Hoje vamos falar das diferenças entre acompanhamento e gerenciamento de projetos. Parece besteira, mas a diferença é enorme.

Acompanhamento é diferente de gerenciamentoVamos imaginar que você esta dentro de um carro em uma ladeira.
No final da ladeira existe um muro, ele esta à uns 3 kilometros de distancia.
O carro começa a descer… você não faz nada
Passou um kilometro e o carro continua a descer… você só vê o muro chegando mas não faz nada
Dois kilometros, a velocidade aumentando e o muro chegando, e você não faz nada.
700 metros, 500 metros, 300 metros, 100 metros… você nada faz
1 metro e pow… bate no muro

O carro demorou 5 minutos para sair to topo da ladeira (com você dentro) e bater no muro

O que você fez neste processo?
Acompanhou, simples assim.

Isto é o “Acompanhar”, você tinha conhecimento da situação, poderia ter tomado alguma ação quando viu que  algo ia dar errado, mas não o fez, apenas acompanhou.

Gerenciar é muito mais que isso, gerenciando você poderia tomar várias ações como:
- Pisar no freio;
- Puxar o freio de mão;
- Tentar fazer um desvio;
- E até mesmo, em uma situação de extrema urgência, pular do carro.

Esta é a diferença.

Em PMC – Monitoramento e controle de projeto ações de gerenciamento devem ser executadas. Possíveis problemas devem ser resolvidos antes que se tornem problemas de fato.
Veja o post completo →