terça-feira, março 04, 2014

Reporting de Risco em Projetos

Os projetos devem ser reportados ao cliente com regularidade, semanal ou mensal. A maioria deles têm muitas vezes regras predefinidas com alguma profundidade para medida do trabalho realizado e seu controlo. Este é o reporting normal de progresso, mas se precisarmos de reportar os riscos e as questões em aberto, como devemos fazer?

 
As normas de gestão de projeto têm alguma orientação para reporting de informação de risco?

Não. A prática de risco do PMI não inclui nada e o PMBoK fala só acerca de relatórios de performance, mas não fornece nenhum detalhe sobre o que devem estes relatórios incluir. Assim, cada um e em cada caso deve ser definida o conteúdo dos relatórios.

 
O que deve ser incluído num interface gráfico de gestão de risco?

Para um relatório para a gestão sénior só deve relatar os riscos em aberto por projeto e / ou os riscos em aberto por categoria (âmbito, orçamento, plano, etc.). isto irá permitir ver se há uma área como o plano em que há maior impacto de risco nos projetos.

Não incluir:

  • Número total de riscos gerais
  • Riscos fechados
  • Riscos com um status de impacto baixo ou médio

A razão para isto é que a gestão sénior não pode fazer muito, se alguma coisa, com esta informação. O número de riscos é por si só uma informação sem significado. Alguns podem ser muito pequenos, alguns projetos podem só ter uns poucos mas podem ser muito significativos. Uma forma melhor seria reportar sobre o impacto do risco – qual o custo de todos estes riscos se ocorrerem?

A abordagem mais adequada será confirmar junto da gestão qual a informação que lhes interessa ver. Não penso que o número de riscos ou os riscos fechados seja informação que eles necessitam para tomar decisões acerca do projeto. Os riscos por categoria, ou riscos com classificação de impacto «alto» são muito mais significativos.

 
Devo mostrar as tendência do risco ao longo dos meses?

Não. O que vai a gestão fazer com esta informação? No início do projeto são identificados muitos riscos e depois fechamos alguns e abrimos novos. Se num determinado mês se realiza uma revisão dos riscos e se identificam mais 50 as tendências vão ficar todas baralhadas. O melhor será em termos de tendências mostrar a situação para um período largo de tempo. Pode utilizar-se uma seta para indicar se o perfil de risco global do projeto está a subir ou a descer, ou usar uma métrica para mostrar se há mais ou menos riscos de «alto» impacto ou se as implicações de custo decorrentes da mitigação de risco subiram ou desceram.

 
E então como reportar as questões e problemas?

Para a gestão sénior só deve mostrar as questões de alta prioridade e em aberto. Em termos de progresso, importa mostrar as questões de «alta» prioridade fechadas durante este mês. Isto mostra o progresso que se está a realizar na resolução de questões, mesmo quando surgem novas questões. Se não fizer dessa forma, o relatório mostrará que existem 20 questões abertas com um status de «alta» prioridade este mês e novas 20 questões abertas. Contudo estas podem ser 20 questões completamente diferentes. Sem muito mais detalhe, como nomes das questões e descrição (o que certamente os sponsors não tem interesse em percorrer), não será fácil ver que estamos a resolver as questões e podem assumir que não estamos a enfrentar os problemas no projeto.

Incluam também as 10 mais importantes questões, com descrições a planos de ação. No caso em que o input dos sponsors é importante para a resolução das questões, não nos podemos esquecer de as incluir no relatório e são salientadas as que necessitam da sua decisão.

Aqui a melhor abordagem é conhecer o que a gestão sénior tem necessidade e pretende saber. Para isso não há como perguntar. Se os sponsors não sabem, apresente-lhes os gráficos e relatórios durante alguns meses e depois peça pelo feedback sobre o que pensam e que mais informação acham que necessitam para desempenharem as suas funções no projeto – tomada de decisão, governação e supervisão.

terça-feira, janeiro 21, 2014

O que espera o cliente do projeto e da equipa?

Logo que começa o projeto, as expectativas de ambos os lados – cliente e equipa - são elevadas e positivas já que tudo é fresco, novo e perfeito. Os pessimistas podem dizer que não há mais nenhum lugar para ir senão para baixo. Na realidade, esta é quase uma situação perfeita com os clientes excitados com o projeto em mãos e, assim, tudo o que se tem de fazer é mantê-los com esse espírito. Pois, mas isso é mais fácil dizer do que fazer.

Temos visto e não poucas vezes que, após os tempos iniciais do projeto, se cria uma atitude «tecnicista» relativamente ao trabalho que afasta a equipa do cliente, e em que se menosprezam as suas expectativas afirmando que o cliente tem desconhecimento das condições ou dos efeitos.

Para que o projeto decorra bem há muitos papéis que o gestor de projeto vai ter de desempenhar ... seja o comunicador, gestor, repórter, decisor, equilibrista de risco e negociador. O cliente olha para estes papéis como a representação de algumas das exigências que são colocadas sobre o gestor de projeto conforme se inicia o empenhamento no projeto em curso. Eu penso que - do ponto de vista do cliente -, há algumas exigências básicas e mais específicas que espera do gestor de projeto quando ele inicia a liderança do projeto no seu caminho para o sucesso. Estes são ...

Comunicação Frequente

Nenhum cliente se sente confortável ​​acerca do estado do projeto quando o gestor do projeto não comunica. Esta é a razão que leva muitas empresas e gestores a serem relutantes em permitir as equipes virtuais e os trabalhadores remotos - eles sentem que se não os veem a funcionar ou não os ouvem o suficiente a falar sobre o seu trabalho, então eles provavelmente não estão a trabalhar o suficiente.

Uma estratégia de comunicação efetiva regular e eficiente deve ser aprovada e executada com elevada regularidade. O cliente tem de sentir que domina as situações por que passa o projeto e sabe que caminhos estão a ser tomados.

Disponibilidade a todo o tempo

Isto parece impossível, porque temos muitas outras coisas a fazer. Mas da forma mais clara e na maior parte do tempo, queremos que o cliente saiba que o seu projeto é único e que tem toda a nossa atenção. Devemos fazê-lo sentir que tem de nós a máxima disponibilidade.

Bom reporting de status

Não se deve deixar nunca o cliente só ao frio sem receber reporting de status. Um bom, claro, atualizado e informativo status é uma condição crítica. O cliente exige-o e espera que as suas expectativas sejam acompanhadas. O relatório semanal é o meio de o cliente justificar a viabilidade do projeto para a gestão de topo. Devemos elaborar o relatório como se devesse ser visto por centenas de pessoas, como se fosse um artigo de jornal. Boa e esclarecedora leitura.

Uma equipa que sabe o que está a fazer

Os profissionais que escolheu para a equipa estão preparados para entregar uma solução de alta qualidade no projeto do cliente. É isso que o cliente espera do dinheiro que está a gastar desde o primeiro dia. Esta é também a atitude que o gestor do projeto tem de fazer ressaltar da atuação e performance da equipa. Qualquer coisa inferior a isso criará desconforto no cliente e levantará questões acerca da capacidade para realizar o projeto. Mantenha os erros, descuidos, conflitos e lapsos de comunicação num mínimo absoluto e conseguirá manter o cliente convencido que estão a obter o valor do dinheiro da equipa e do gestor do projeto.

Atualize o agendamento do projeto

Finalmente, prepare o cliente para receber previsões atualizadas do agendamento do projeto todas as semanas. Sobretudo se for necessário prócer a mudanças críticas. Nunca assuma que o cliente não olha ou não sabe ler o cronograma do projeto. Podem até não olhar para ele muitas vezes … porque confiam no nosso bom reporting de status, mas não se esqueça que um cronograma é para muitos clientes como que uma obra de arte, podem não o examinar em muito detalhe e podem mesmo não o compreender totalmente ou interpretá-lo com correção, mas é um grande gráfico para pendurar na parede e dizer à gestão de topo «Olhem o que estamos a realizar!».

quarta-feira, dezembro 04, 2013

Não culpem as pessoas! Culpem os processos!

Ter bons processos confiáveis ​​é a pedra de toque para um negócio com sucesso. Os processos estão lá para garantir que há consistência e robustez para as actividades repetitivas.

No entanto, nem todos os processos são bons processos e, no pior dos casos, podem realmente fazer recuar o negócio. Isso ficou claro num projecto em que trabalhei recentemente ...

O projeto bloqueou porque o processo de implementação da infra-estrutura de TI não tinha sido devidamente comunicado e os decisores não foram identificados. O departamento de TI ofereceu uma ajuda muito reduzida nas fases iniciais do projecto. Logo, ficou claro que algo estava errado, especialmente porque os membros da equipa, que pretendiam o sucesso do projecto estavam a ser fortemente condicionados pelo próprio processo. Um caso claro de um processo mal pensado e pesado que atrasa um projecto importante para o negócio. Então que lições podemos aprender com isso?

 

O processo demorado

Não culpe as pessoas, porque você tem processos grandes e pesados​​. Pergunte se os processos estão adequados à finalidade. Se você estiver obrigar as suas pessoas a ultrapassar muitos obstáculos e eles resistem, então você está preso num "processo de corrida de obstáculos".

O que fazer: Rever e simplificar seus processos. Verifique se não há papéis e responsabilidades que sejam claros e você preste contas em todos os cenários e não apenas o principal. Teste a execução dos seus processos em papel com as pessoas que vão usá-los e melhorá-los a partir do seu feedback.

Como sabemos, bons processos são um caminho para o sucesso. Por outro lado, os processos mal concebidos são um caminho para o fracasso. Processos pobres são muitas vezes escondidos se os "heróis" da organização continuam a entregar projectos apesar dos processos. Não presuma que o sucesso do projecto é igual a bons processos, há sempre espaço para melhoria.

O que fazer: Converse com as pessoas para entender onde estão os pontos quentes e bloqueios, e atualize os processos para os remover.

 

Processo de impasse

Se um processo resulta num impasse que você deve considerar se está apto para o efeito para que foi criado.

O que fazer: Com qualquer processo, deve certificar-se que nunca alcança um ponto em que se fica incapaz de continuar.
 

Keep it Simple

Você pode ter ouvido a sigla 'Kiss' quando se trata de práticas e processos de trabalho. Ela representa, 'Keep It Simple Stupid " e enquanto eu não defenderia o uso deste com os seus colegas e clientes, você pode mantê-lo em mente ao criar novos processos ou melhorar os já existentes.

Os melhores processos são aqueles que são mantidos simples. Elas são fáceis de entender e de ter etapas e resultados claros.

O que fazer: Olhe para cada etapa de um processo e pergunte se é mesmo necessária. Ela pode ser removida? Será que ajuda a mover em direção ao objetivo? Quanto menos etapas de um processo melhor, então acho que é 'Kiss'.
 

Em resumo

Se se tornar demasiado orientado para os processos arrisca-se a perder de vista o objetivo do negócio. Certifique-se de mantem os seus processos simples, verifique-os com as pessoas que irão utilizá-los e evite processos que podem resultar acabar num impasse. Bons processos irão conduzir o seu negócio em direção aos seus objetivos, mas os processos pobres podem e irão atrasar o negócio.

Se as coisas não estão a funcionar, não culpe as pessoas, culpe os processos e tome medidas para os melhorar.