GP em Destaque

É uma orientação documentada para que o trabalho do projeto seja executado de modo que seu desempenho futuro esperado fique de acordo com o plano de gerenciamento do projeto ( fonte:  PMBOK 4ª Edição )

Observe que na própria definição temos que esse tipo de ação é necessária para que no futuro o projeto esteja de acordo com a linha de base do projeto, ou seja, neste momento o projeto já se encontra em divergência em relação ao planejado. A ação corretiva se difere da ação preventiva, pois é realizada após um desvio do plano, ao passo que, a ação preventiva é realizada para que o desvio não ocorra.

Supondo um cronograma atrasado em 5 dias devido a fortes chuvas que ocorreram e a estrada foi totalmente destruída. O meio de transporte contratado foi caminhão. Será que uma ação corretiva em solicitar a entrega do equipamento através de um meio de transporte aéreo não diminuiria o impacto no cronograma. Lógico que, toda ação corretiva deve ser analisada para que tenhamos o impacto em outras áreas do projeto.

Reforçando:

• Ação corretiva -> já houve o desvio
• Ação preventiva -> evitaria o desvio

Segundo o PMBOK, ação preventiva é uma orientação documentada para a realização de uma atividade que pode reduzir a probabilidade de consequências negativas associadas a riscos  do projeto.

Um exemplo claro em que a ação preventiva não está sendo considerada ou até mesmo ignorada é a quantidade de pessoas que ainda permanecem em suas casas em áreas de riscos de deslizamentos. Tanto por parte delas, tanto por parte do governo que faz de conta que está preocupado com essas famílias, porém, nem mesmo identica ou realiza o planejamento de uma ação preventiva para o próximo período de chuvas. Ou seja, 1 ano sem fazer nada e depois gastando milhões com as ações corretivas ( falaremos em um post posterior sobre as ações corretivas )

Prevenir é melhor que remediar….

Um fato que ocorre constantemente nas organizações é grande politicagem existente entre algumas áreas do cliente com alguns fornecedores.

Em uma consultoria que realizamos alguns anos atrás, presenciamos o seguinte cenário:

A Empresa “Confie em nós” fechou um contrato de outsourcing com o cliente onde todos os ações corretivas seriam dessa empresa. E os projetos, seria dada a preferência para essa empresa, porém, se essa não tivesse fôlego ou capacidade para realização do projeto esse poderia ser direcionado para outra empresa concorrente. Até aí, tudo bem…Será ?

Pois bem, em um determinado projeto, e não era qualquer projeto, a área cliente solicitou que o projeto não fosse conduzido pela empresa “Confie em Nós” ( vencedora do outsourcing), assim uma nova empresa foi convidada a enviar a proposta comercial.

No momento de fechar o projeto, um dos gerentes da área cliente informou que o projeto deveria ser fechado com a empresa titular, independente da capacidade ou fôlego para a realização do projeto. Essa decisão foi tomada a partir de um contato entre o diretor da empresa fornecedora ( “Confiem em Nós… Mais Ainda” )  e o gestor da área.

Resultado: a empresa sem profissionais com capacidade para conduzir o projeto, os usuários que utilizarão o produto não queriam a empresa por alegar alto risco, o custo seria superior, ai vem a pergunta: Por que fechar o projeto com a empresa “preferida” ?

Será que o gestor do projeto deve considerar a politicagem como um risco do projeto ?

Qual a chance de sucesso deste projeto ?

Pessoal,

analisando a ação que durou 69 dias para resgate dos mineiros no Chile, podemos constatar que o projeto foi concluído com sucesso.

A equipe corria contra o tempo, a cápsula foi construida no improviso, o estudo da melhor rota para chegada aos 700 metros de profundidade foi escolhida, as medidas de segurança foram exaustivamente checadas a cada mineiro resgatado, ou seja, tudo perfeito.

Imagine um cronograma tendo como data limite o tempo de vida de 33 mineiros, a necessidade de conclusão era o quanto antes para o salvamento, mas mesmo com pressões extremas o planejamento foi realizado de forma cautelosa e sensata.

A gestão de riscos se destaca, tanto durante a fase de análise das rotas e posicionamento como no monitoramento e controle durante todo o resgate.

A gestão dos stakeholders ( famílias, mineiros, políticos ) foi realizada de forma com que todos tivessem seu momento ao sol, satisfazendo as expectativas de cada um.

Concluindo… um grande projeto que ficará para a história de nossa comunidade de GP.

Parabéns a equipe de resgate, pelo planejamento e sucesso neste projeto.

Olá Pessoal,

é com grande satisfação que comunicamos que foi reativado o Escritório Regional do Triângulo Mineiro vinculado ao capítulo de Minas Gerais.

No dia 09/09, foi realizada a primeira reunião com os novos membros do comitê, onde já definiram as próximas atividades do escritório, além da nomeação do representante do escritório junto ao PMI-MG.

O escritório visa atuar sob a gestão do PMI-MG com o objetivo de disseminar as ações do PMI na região de Uberlândia e Triângulo Mineiro, demonstrando os benefícios da filiação, além da promoção de eventos e disseminação de conhecimentos.

Os interessados em saber mais sobre essa frente, fiquem a vontade em nos contactar.

Abraços

Um dos tópicos do código de ética e conduta do gerente de projetos é justamente promover uma interação entre os stakeholders ( partes interessadas )  do projeto.

Para isso, é necessário equilibrar os interesses de todas as partes, solucionar os interesses conflitantes, lidar com problemas e conflitos assim que surgirem,  interagir com a equipe e as partes interessadas de forma profissional e cooperativa, identificar e entender as diferenças culturais e ainda descobrir as preferências de comunicação ao identificar as partes interessadas.

Observem que são pontos importantes para que tenhamos um objetivo  comum entre os envolvidos do projeto. Estamos considerando aqui que todas as partes interessadas foram identificadas, neste momento estamos discutindo a forma com que as necessidades dessas partes serão atendidas pelo projeto.

É lógico que nem todas as necessidades poderão e serão atendidas, uma vez que o gerente de projeto deve analisar o impacto junto ao objetivo macro do projeto, declarado pelo sponsor ( patrocinador ) no termo de abertura, ou seja, se determinado stakeholders possui uma necessidade “relacionada” ao projeto porém não faz parte do objetivo do projeto, com certeza essa necessidade deverá ser deixada de lado.

As partes interessadas devem ser envolvidas e interadas de acordo com o plano de comunicação, porém, sempre de forma clara e transparente. É necessário que seja baseado no plano de comunicação, pois nada mais desagradável que um diretor de uma organização receber um relatório técnico da equipe.  Neste caso, a informação que deveria chegar neste nível da organização seria somente o status do projeto e os pontos críticos de atenção.

Resumindo, uma coisa é promover a interação das partes interessadas, outra coisa é enviar informações a todos e permitir que todos comuniquem em qualquer direção sem um planejamento adequado.

Recentemente, participei de uma reunião junto a um integrante da área fiscal de uma empresa. A reunião tinha o objetivo de definir algumas questões tributárias. Após concluirmos todos os tópicos da reunião, esse colaborador solicitou que constasse na ata de reunião, a necessidade do gerente de projetos ser um especialista na área do projeto, no caso, era um um projeto no ramo de telecom, porém, iria envolver as áreas diversas como produto, financeira, TI, fiscal e jurídica. Como ter um gerente especialista nesta situação ? Acho MUITO difícil….

Achei surpreendente essa colocação, uma vez que, o termo de abertura do projeto já havia sido elaborado e o gerente de projeto designado ( após análise pelo sponsor do projeto ). O interessante é que o gerente do projeto era uma pessoa que não era especialista em telecom, apesar de ter vivência em telecom por mais de 5 anos, mas nem por isso o tornava especialista.

Então fiquei analisando o motivo das pessoas acreditarem que um gerente especialista seria melhor para o projeto.  Se fosse um projeto que envolvesse somente uma área ( financeira, por exemplo ), teríamos facilidade em designar um gerente especialista, mas neste caso, não.

Neste tipo de cenário, um gerente generalista seria mais interessante, pois, o gerente teria que se preocupar em integrar os especialistas para que pudessem agregar ao projeto. Ou seja, o gerente não tem que saber TUDO e sim envolver pessoas com perfis e conhecimentos diferentes, especializados em sua área de atuação e que juntos possam atingir o objetivo do projeto.

Certa vez, analisando uma empresa TI, constatei a divergência de opiniões em relação ao sucesso dos projetos.

Para a equipe técnica, sucesso seria entregar o software todo encapsulado, utilizando o que havia de melhor em aquitetura, linguagens, documentação técnica, etc.

Para a gerente comercial sucesso era a entrega do projeto no prazo, uma vez que a uma parcela da comissão pela venda estava vinculada a ultima entrega. ISSO É VERDADE !!!

Para o diretor ? Para ele o projeto não tinha importância, pois o cliente não era preferencial. ISSO TAMBÉM EXISTE, OK ?

Para o cliente, esse sim, estava preocupado com a qualidade dos artefatos produzidos ( tecnicamente falando e também em perfeito funcionamento ), o prazo de entrega, o custo ( que neste caso já havia sido acordado comercialmente com a empresa terceira ). Ou seja, o cliente espera nada mais, nada menos, do que aquilo que havia sido acordado na declaração de escopo e/ou na proposta comercial / contrato de trabalho.

No ponto de vista da empresa que executa o projeto, neste caso o fornecedor, o sucesso do projeto poderia se caracterizar por todos os itens do ponto de vista do cliente MAIS a conclusão do projeto sem estouro no orçamento ( uma vez que neste caso, o projeto havia sido fechado através de uma negociação de preço fixo ).

Resumindo:

O sucesso do projeto caracteriza-se por atender ou superar as expectivas do cliente sem estouro do orçamento e prazo na ótica do fornecedor.

A reunião de kick-off em um projeto é essencial e não deve durar mais que 1 hora, para que não tenhamos detalhes excessivos nesta reunião.

É importante a presença dos principais stakeholders do projeto, inclusive com a participação do sponsor ou patrocinador, pois assim o projeto já inicia com o envolvimento e interesse de todos.

A reunião deve ser coordenada pelo gerente de projeto, onde os principais tópicos apresentados são: o objetivo do projeto, o escopo macro do projeto, os principais riscos e restrições, possível orçamento estimado e data de entrega. Essas seriam as informações contidas no termo de abertura do projeto, ou seja, as informações de suma importância porém de forma que não detalhe muito, uma vez que o planejamento do projeto ainda não foi realizado.

É nesta reunião que teremos o comprometimento e motivação da equipe, pois nada pior que iniciar um projeto e a equipe nem saber do que se trata o projeto e qual a importâcia dele para a organização ou sociedade.

Por menor que seja o projeto, é necessário que exista a reunião de kick-off.

Assim, vamos investir 1 hora de toda a equipe e economizar muito no decorrer do projeto.

É muito comum, um gerente de projetos assumir um projeto semelhante a outro projeto que ocorreu no passado ( suponhamos há 2 anos atrás, gerido por outro gerente ).

O que seria mais fácil ? Buscar fontes de como foram os erros e os acertos do projeto anterior OU simplesmente planejar e identificar tudo novamente ?

Lógico que, com base em informações históricas, o gerente do projeto teria mais tranquilidade em planejar o projeto, uma vez que poderia identificar os pontos importantes que ocorreram em projetos passados.

TODO PROJETO deve ter suas lições aprendidas registradas pois assim tem-se um ganho considerável nos projetos futuros. Esse registro deve ser em um local onde os demais gerentes de projetos possam ter acesso. Nada adianta , se houve o registro das lições aprendidas e ninguém tem acesso as essas informações.

As lições aprendidas devem ser registradas durante todo o projeto e na fase de encerramento elas devem ser revisadas e consolidadas. É muito importante considerar as informações de toda a equipe e não somente do gerente de projetos.