Riscos Inevitáveis

Por mais simples que seja, em nossos projetos sempre levantamos os principais riscos que podem ocorrer, seus gatilhos, impacto e probabilidade entre outros itens.  Dentro do planejamento realizado é verificado se esses riscos serão, mitigados, aceitos ou evitados.

Porém existem certos problemas que apodemos esquecer de colocar em nossos projetos ou mesmo não temos como saber que poderia ocorrer.

Alguns desses riscos podem ocorrer quando os projetos englobam diferenças de culturas, diferentes regiões, cidades, países.  Um exemplo dessa diferenças por exemplo ocorreu em um projeto em que participei, onde o cliente , que estava a fazer testes ligou informando que alguns dias dos testes iriam atrasar devido ao carnaval. O problema aí estava no planejamento do cronograma, realizado em uma determinada cidade que não possui tradição de carnaval e suas empresas costumam trabalhar neste período, enquanto o cliente localizava-se no Rio de Janeiro, onde a tradição do carnaval é influi diretamente.

Porém existem certos riscos que não conseguimos evitar, eles ocorrem, necessitam de atividades complementares , necessitam de tempo e aumentam o custo do projeto. São riscos como catástrofes naturais por exemplo.

Cinzas de um vulcão cancelando voos em continentes por milhares de quilômetros, enchentes devastando cidades, terremotos , tsunamis, etc. Lembro que li uma matéria na PM NetWork de Maio de 2011 uma matéria intitulada Shaken to the Core o qual comentava sobre um projeto de mudança na parte de TI do Wallmart no Chile, gerenciado pelo Sr. Michael Allen bem na época em que ocorreu o terremoto que abalou todo país.  Para este tipo de problema é que temos a “gordura” representada no orçamento. Quando algo deste tipo ocorre, todo plano do projeto deve ser revisto, grande parte dos stakeholders são afetados.

No caso do terremoto no Chile ocasionou em 3 meses de atraso no projeto de TI, replanejamentos e reestruturação do projeto. Em casos assim não há como evitar o ocorrido, tampouco prever que isso ocorreria, deve-se aceitar os fatos e buscar a melhor alternativa para  proceder o projeto e conseguir o seu sucesso.

Insper Connects – Da Gestão de Riscos em Projetos a... Resultados em Projetos

Ajudando na divulgação de eventos da nsos área:


Insper Connects promove encontro para debate sobre Gestão de Riscos em Projetos.


No dia 29 de março, o Insper lança o Insper Connects, conjunto de eventos que tem o objetivo de promover network, debates e palestras sobre diversos temas de Negócios e Economia. No evento de estreia, “Da Gestão de Riscos em Projetos a... Resultados em Projetos”, o consultor Pedro C. Ribeiro, sócio-diretor da Stratech/TheProjectOffice, especializada em consultoria e treinamento em estratégia e gestão de projetos e riscos detalhará como a gestão de riscos pode ser um importante instrumento para alcançar os objetivos da organização.

Com moderação do professor e coordenador do Insper Guy Cliquet, o encontro é voltado para gerentes de projetos e profissionais envolvidos com gestão de risco, atuantes em todos os setores da economia.

O evento tem apoio do PMI, Project Management Institute, principal associação mundial de gerenciamento de projetos, que pede aos participantes para fazerem uma doação de mantimento não perecível ou brinquedo para crianças de 0 a 4 anos. As doações serão destinadas ao Instituto Segatto, que tem como missão promover a comunicação, o desenvolvimento humano e contribuir para o fortalecimento da educação.

As vagas são limitadas e os interessados devem fazer a inscrição pelo site www.insper.edu.br/connects.

Insper Connects – Da Gestão de Riscos em Projetos a... Resultados em Projetos

Data: 29/03 (terça-feira)

Horário: 19h

Local: Insper – Auditório Max Feffer – Rua Quatá, 300, Vila Olímpia, São Paulo – SP

Inscrição: www.insper.edu.br/connects

Entrada: doação de mantimento não perecível ou brinquedo para crianças de 0 a 4 anos ao Instituto Segatto.

Templates

Li recentemente uma matéria sobre a  utilização de templates para as documentações utilizados nos projetos. Quando estava iniciando em Gerenciamentos, utilizei muitos templates, para montar Termos de Abertura de projetos, planos de projetos, termo de encerramento, etc, e ainda hoje em dia utilizo. Porém os templates prontos são muito uteis quando já se formulou um processo, uma metodologia de desenvolvimento a ser seguido mantendo assim um padrão com as informações necessárias na sua organização. 

Porém, quando ainda não se possui um processo definido e busca-se montar as documentações de projetos deve-se tomar muito cuidado com os templates a serem utilizados. Muitas vezes os templates possuem muitos termos que nem sempre necessitam ser utilizados. Por exemplo, para projetos grandes, necessitasse de uma grande quantidade de documentações, porém para projetos pequenos não necessariamente precisa-se todas as documentações. 

Um certa ocasião montei um pequeno projeto de software com uns amigos. A primeira idéia era montar todo um planejamento documentando tudo sobre o projeto, criar um plano de risco, cronogramas, levantar todos os requisitos, apontamento de horas, etc. Porém o projeto ainda era pequeno, ainda estávamos levantando as informações, não havia ainda conhecimento profundo de negócio e conhecimento técnico por parte dos membros da equipe. A tentativa de criar uma documentação aprofundada sobre um projeto onde não se havia ainda uma metodologia ou conhecimentos necessários não deu certo. 

Para este tipo de projeto buscamos documentações mais apropriadas, menos complexas, utilizamos scrum, que é uma metodologia em que as documentações são mais enxutas.

Já para projetos grandes temos que ter um organização maior, muitas pessoas formando projetos diferentes porém que possuem processos padronizados e nesse caso são essenciais  para que tenhamos o controle e verificação de todas as documentações dos projetos, seja para o projeto em si ou para consultas de outros projetos.

Em resumo, a utilização dos templates deve ser vista para cada caso. Muita documentação pode tomar tempo do projeto em partes burocráticas e que dependendo do projeto pode tomar muito tempo.

Outro ponto importante é que para pessoas que estão iniciando como GPs, devem tomar cuidado para não se prender aos templates, eles ajudam a verificar as informações necessárias dos projetos, porém podem prender os GPs a ficarem presos em documentações e não olharem atentamente para o que realmente o projeto necessita. Cuidado para não entrar em rotinas desnecessárias com informações incompletas ou repetitivas no seu projeto.

Att.

Marcus Machado

Mudança de visão: Aceitar o Replanejamento durante o Projeto

Olá, outro dia estava lendo uma reportagem sobre o replanejamento das atividades nos projetos e achei interessante a seguinte visão: todos comentam que uma coisa que se tem certeza em um projeto é de que haverão mudanças. 

O que fazer com essas mudanças? Devemos Trata-las, evita-las, até que ponto devemos levantar informações e fazer estudos sobre os impactos destas mudanças?

Pelo PMBOK e as boas práticas do PMI é recomendado que na parte de planejamento de um projeto seja feito um estudo sobre as possíveis mudanças no projeto, o impactos dos riscos, os caminhos de tratamento dessas mudanças, mitigando , aceitando ou evitando as mudanças em relação ao escopo planejado. Este tipo de planejamento é muito bem aceito quando tratamos de projetos em que sabemos exatamente o que deve ser feito e como deve ser feito. São projetos em que se tem conhecimento claro do objetivo, requisitos e características. 

Nesse tipo de projeto é mais fácil considerar as possíveis mudanças, antecipar e tratar suas consequências em busca de se manter o objetivo final.

Em alguns projetos, como projetos de software, por mais que seja feita uma analise preliminar do escopo, levantamento de requisitos, objetivos do projetos, normalmente ocorrem muitas mudanças desde da parte do contratante, tecnologias aplicadas, objetivos finais, etc. Esses tipos de projetos em que normalmente não há um conhecimento afundo do objetivo, conhecimento de negócio e conhecimento da tecnologia possuem um nível de mudanças muito maior, e normalmente para que essas mudanças não tragam uma diferença muito grande no final do projeto em relação a prazos e custos costumamos colocar uma margem grande “gordura” aumentando o custo total do projeto o que não agrada clientes , onde muitas vezes a própria empresa se responsabiliza com esses custos e acaba dando um tiro no pé.

Para projetos deste tipo o mais interessante seria trabalhar sabendo de que o escopo final pode mudar, sabendo que as mudanças vão aparecer e terão que ser tratadas. Nesse casso o mais interessante é quebrar a definição do escopo em blocos de atividades se for possível, e quebrar as entregas alinhando com o contratante que a forma de trabalho será essa. 

Com entregar antecipadas de parte menores do projeto alguns problemas de tecnologia e visão de negócio podem ser antecipados e alguns problemas que ocorreriam várias etapas do projeto podem ser vistos antecipadamente desde que as lições aprendidas e a comunicação (relatórios e reuniões de acompanhamento) sejam feitas periodicamente.

Para quem trabalha com Scrum sabe que antecipando as entregas em partes menores (período das sprints) e trabalhando a mudança junto ao cliente se possível evitam que requisitos que no inicio pareciam importantes sejam criados (e depois nunca são usados pelos clientes) e que correções e modificações necessárias sejam verificadas o quanto antes , pois quanto mais tarde verificado no projeto mais caro sai a correção .

Tudo isso vai depender do seu projeto e do bom senso, pelo PMBOK a idéia é planejar da forma mais detalhada possível as informações para evitar problemas na execução, porém atualmente para determinados tipos de projetos sabemos que trabalhar com entregas menores, acompanhamentos constante e buscando resolver as mudanças o quanto antes diminui os impactos negativos e antecipa possíveis problemas de discordâncias de requisitos por parte dos contratantes.

Marcus Machado

Projecta Joinville 2010 - Habilidades e Ferramentas para o Gerenciamento de Projetos