quarta-feira, dezembro 21, 2011

Principais Categorias de Riscos

Abaixo descrevemos algumas das áreas que devem ser averiguadas (ou pelo menos visitadas) para verificar se existem alguns riscos escondidos ao longo de todo o projecto. Pode funcionar como um embrião para a criação de um Registo de Riscos para utilizar em projectos. Então aqui vai:
Riscos relativos ao Âmbito – Deslizar potencial do âmbito porque os requisitos do projecto não estão definidos com clareza. Foi bem definido o critério de performance? Estão definidas todas as condições limite? Onde começa e acaba o trabalho? Foram definidas as responsabilidades de todas as partes nas diferentes fases do projecto? Foram definidos os procedimentos de gestão da mudança do âmbito? 
IMG00012-20101031-1140
Riscos relacionados com o Plano e o Esforço
– O deslizar do âmbito é um risco de grande dimensão para o plano e o custo mas estimativas de qualidade pobres são também um factor significativo. A falta de experiência anterior. Conhecimento experimentado da área de actividade, falta de adequadas revisões e verificações são as causas para estimativas inexactas. Ser pessimista faz-nos ganhar pontos e devemos quase ser paranóicos quando se trata da estimação do projecto. O optimismo mata, muitas vezes!

Riscos relacionados com Assumpções – Será que definimos com clareza todas as assumpções do projecto na especificação de trabalhos? E elas cobrem todos os aspectos importantes e as fases do projecto? Já foram documentadas as actividades a realizar se uma assumpção se comprovar como errada e evolui para ser um risco para o projecto? Já fez a revisão com o cliente / sponsor as assumpções e as contingências para cada uma? Todas as assumpções, num projecto ideal, devem ser registadas e visitadas em cada relatório de status e revisão de projecto

Riscos relacionados com Dependências
– O projecto está dependente de stakeholders múltiplos como, por exemplo, cliente / sponsor, fornecedores, empreiteiros, agências externas, etc. e para cada dependência irão existir riscos associados. Teremos de garantir que todas as dependências são documentadas e que: estão registadas as entregas que devem ser realizadas por cada parte? Garanta que as linhas de tempo para as entregas de cada parte estão claras para todos e comprometidas? E mencionou neste compromisso qual é a contingência se se materializar o risco e o compromisso não é alcançado pelo stakeholder? Todas as dependências devem ser registadas e visitadas nos relatórios de status e nas revisões do projecto. Alguns exemplos destes riscos são – atraso do fornecedor, problemas de entregas, questões com empreiteiros, atrasos do cliente, atrasos de envio, etc.


Riscos relacionados com Constrangimentos
– Quase todos os projectos têm algum tipo de constrangimento. O exemplo deste constrangimento pode ser limitados recursos para a execução, elevado custo dos produtos envolvidos, tempo de execução muito apertado, condições apertadas de extensas de garantia, etc.


Riscos relacionados com a Tecnologia
– A tecnologia seleccionada pode colocar riscos em dependência das suas limitações. Isto é especialmente verdade se a tecnologia é recente e pouco comprovada ou não é conhecida se for necessário suporte técnico. A limitação da tecnologia pode ainda inibir a interoperabilidade futura entre sistemas. A mesma tecnologia pode colocar problemas se estamos ainda a funcionar com versões antigas e o fornecedor passou a novas versões. A obsolescência electrónica de equipamentos é um risco de grande dimensão quando tratamos de os embeber no desenvolvimento do produto muito especialmente se necessitamos de garantir o suporte destes produtos por longos anos.


Riscos relacionados com os Critérios de Aceitação
– Uma causa importante de preocupação para o gestor de projecto está na definição no contrato de critérios de aceitação vagos ou pouco claros. Este também é um aspecto muito difícil de definir nos estágios iniciais do projecto quando se define a especificação do trabalho. Deve preparar um plano de teste da aceitação logo que os requisitos estejam fixos e a arquitectura de alto nível esteja realizada. Em alguns projectos esta importante questão só é tratada já tarde no projecto e esto deixa este exposto a um risco inaceitável.


Riscos da Regulação
– A equipa de projecto tem de avaliar cuidadosamente os requisitos regulatórios e de certificação pra o produto e avaliar o seu impacto nos colaboradores do projecto, no desenho do produto, e no orçamento e tempo de realização do projecto. Se nada foi feito então estamos a enfrentar um risco maior, que deve ser regularmente acompanhado. Este tipo de riscos pode ter um alto impacto no projecto e reflectem-se no custo e no tempo com impactos significativos na satisfação do cliente / sponsor.


Riscos relacionados com Pessoas
– Estes incluem conflitos, falta de competências, experiência, moral, motivação, relações da equipa, etc.


Riscos relacionados com a Experiência e as Competências
– A disponibilidade de conhecimentos sobre a actividade pode ser um requisito importante em muitos projectos. Este conhecimento especializado pode ter a ver com a indústria ou com os domínios de tecnologia. O projecto pode necessitar destes peritos para desenhar um sistema que seja de confiança, que passe nos testes de certificação e que satisfaça as necessidades do utilizador final. Se estes conhecimentos especializados são necessário então desenvolve-se uma dependência e um risco associado. Um conflito com este tipo de especialização pode debilitar o projecto.


Riscos Políticos
– Não podemos negligenciar este importante aspecto em qualquer projecto. Será que o projecto tem o compromisso adequado dos mais importantes apoios? E o sponsor do projecto será que ele tem o suporte e o financiamento da gestão? Quem é que sofrerá o impacto do projecto? E a sua colaboração é necessária durante a execução? Que precauções devem ser tomadas se algum stakeholder importante da organização cliente se recusar a cooperar? Quem é que deverá o cliente contactar se quiser levantar uma escalação? Foi criado um ponto de contacto entre a organização da equipa de projecto e a orgânica da organização cliente?


Riscos relacionados com a Garantia
– Diferentes contractos têm diferentes cláusulas. O plano do projecto deve ter em consideração e planear para a os termos da garantia definidos para este projecto. As cláusulas de garantia, numa visão ideal, deverão descrever o tipo de suporte que será fornecido ao cliente / sponsor durante a fase de garantia. Não é anormal vermos cláusulas de garantia por múltiplos anos e estas colocam grande risco. Como é que se retém o conhecimento da equipa por este período de forma a cumprir os compromissos? Como se mantém as licenças das ferramentas durante este período? Como se enfrenta a obsolescência das ferramentas vitais e do equipamento?


Riscos relacionados com Penalidades – Muitos contractos incluem cláusulas de penalidades relacionadas com a performance da equipa de projecto. As estimativas iniciais devem ter em conta estas penalidades potenciais. Pode ser necessário entrar em linha de conta com a potencial perda de rendimento devido a penalidades de atraso criando uma margem adicional de contingência.

Riscos relacionados com a Qualidade
– O que é que pode ir mal no que respeita à qualidade do produto? Os exemplos para pobre qualidade são pobre performance, interface difícil de usar, produto mal desenhado, reduzida confiança, etc. ajuda definir os parâmetros críticos para a qualidade para o produto logo cedo, como parte do âmbito e, em seguida, medir a qualidade do produto contra estes critérios.


Risco de Mercado
– O produto foi construído mas o mercado coloca riscos significativos se o produto tem má ou errada funcionalidade, qualidade pobre, custos elevados, é difícil de usar, não passa nos testes de certificação, é difícil de produzir, é difícil de manter ou é atrasada a sua introdução no mercado.


Desastres Naturais
– Estes riscos são muitas vezes ignorados pelos gestores de projecto porque lhes parecem estar para além da sua esfera de influência. Mas estes riscos devem ser registados no planeamento de grandes contractos e programas. Os planos de resposta ao risco devem ser documentados e em posição para que a equipa possa responder na eventualidade de ocorrer algum desastre. O propósito é minimizar o dano tanto quanto possível e por essa forma não é possível realizar a eliminação total do risco. A mitigação deste tipo de riscos são a diversidade geográfica, uma gestão robusta do conhecimento e documentação actualizada, para garantir um mecanismo de comunicação efectiva que possa em tempo sincronizar todos no mesmo propósito.

terça-feira, dezembro 13, 2011

Categorias de Riscos a ter em atenção

Os riscos são inevitáveis nos projectos. Não podemos evitar os riscos e conseguir uma suave execução do projecto. Temos somente de aceitar este facto e afastarmo-nos dos riscos iminentes. Estes eventos de risco estão muito bem escondidos em lugares dos mais improváveis, mas confiamos sempre em que o bom tempo e a bonomia dos nossos concidadãos nos permitam alcançar algum sucesso sem sermos confrontados com um destes eventos prováveis.image

Os gestores de projecto pesquisam os riscos em locais conhecidos ou dependem por completo da experiência quando identificam riscos potenciais no seu projecto. O seu registo de riscos vai melhorando conforme eles adquirem experiência. Mas este tipo de educação é muito dispendiosa para o projecto e para o sponsor do projecto. Uma exploração sistemática de riscos em áreas problemáticas conhecidas deve ser uma obrigação em todos os projectos. Esta exploração deve ser sistemática e deve, para facilitar, ser realizada com a utilização de uma lista de verificação. Não se pode deixar um aspecto tão crítico do projecto para a memória do gestor de projecto. Esta lista deve ser um documento vivo e deve ser actualizada sempre que factos novos ou conhecimentos estejam disponíveis durante a execução dos múltiplos projectos.

Em sumário, o gestor de projecto deve ter atenção às seguintes áreas de risco:

  • Âmbito
  • Plano e Esforço
  • Asumpções, Dependências e constrangimentos
  • Tecnologia
  • Critérios de Aceitação e Qualidade
  • Pessoas, experiências e competências
  • Regulação e Política

Todas estas áreas correspondem a uma lista de perguntas que os gestores de projecto devem colocar quando, de forma obrigatória e regular, abordarem a revisão de riscos para o projecto.

quarta-feira, dezembro 07, 2011

O jogo do projecto – uma fábula

Agora uma fábula, já que de jogo se trata. Imagine um rei que é solteiro e quer ter um herdeiro. Ele pede a 3 membros do seu conselho para gerirem um projecto e recebe as respostas seguintes:

  • O primeiro conselheiro diz que ele consegue organizar a produção de um herdeiro em 4 meses.
  • O segundo conselheiro declara de 3 a 5 anos, tendo em consideração a necessidade de encontrar um cônjuge adequado, seguir protocolos complexos de noivado real, casamento e deixar a natureza realizar o seu curso.
  • O terceiro afirma 9 meses.

imageConsiderando que o rei funciona como a maioria das companhias, quem é que ele vai seguir?

A proposta do primeiro conselheiro é fisicamente impossível, quaisquer que sejam os recursos que se atribuírem à actividade. O segundo conselheiro parece ao rei demasiado cuidadoso. O terceiro conselheiro recebe o projecto, porque ele está a propor um plano agressivo mas que não é impossível. O conselheiro reconhece que o prazo não vai ser alcançado, mas pode enfrentar isso mais tarde. O rei sabe também isso, mas aposta em que o conselheiro redobrará os seus esforços para evitar o fracasso e conseguir entregar em tempo. Quatro meses e onze meses depois, nasce um príncipe.

Neste tipo de situação, a duração das actividades usada no planeamento do projecto são as mais curtas que não violam as leis da física. Os gestores do projecto fazem a venda nesta base, falham os prazos e trabalham desesperada e vigorosamente para o concluir. Como resultado de sobreviver neste jogo, são promovidos e continuam as mesmas práticas na geração seguinte.

O jogo não tem de ser jogado desta forma, mas a iniciativa deve vir de cima. Soichiro Honda estabeleceu um tom diferente no desenvolvimento da sua companhia, ao envolve-la nas corridas de motos. Quando participava numa corrida nada mais interessava a não ser que o veículo, o piloto, a equipa e os fornecimentos estavam colocados e prontos no início da corrida. Este tipo de prazos rígidos também encontramos em coisas como concertos de música, a organização de exposições em museus ou o lançamento de uma sonda espacial para voar para os planetas do sistema solar. Esta abordagem foca as equipas de projecto em realismo, avaliação das actividades e criatividade para enfrentar o inesperado.

terça-feira, dezembro 06, 2011

O Jogo do Projecto

Iniciei o trabalho com uma equipa de projecto de uma grande companhia que está a preparar a realização de uma obra de grande dimensão – que é mesmo o propósito da mesma companhia e veio-me à cabeça um turbilhão de ideias com os problemas enfrentados no início de um projecto e com as concepções diversas que se tem sobre a gestão de projecto.

O desenvolvimento dos grandes projectos de engenharia como a ilha Jumeirah no Dubai ou o desenvolvimento do Airbus A380, são concluídos com atraso de perto de dois anos relativamente ao plano. Estes são só dois exemplos, mas essa é uma constante porque esta performance dos projectos não é uma excepção. Desde a remodelação da cozinha até ao desenvolvimento de um produto, os projectos tendem para estar atrasados no tempo relativamente ao plano ou acima do orçamento, ou ambos. image

É tecnicamente possível fazer melhor mesmo em projecto de grande escala, com envolvimento de nova tecnologia como o exemplo do programa Apollo, que alcançou o seu propósito 5 meses antes do prazo, ou, para falarmos de um exemplo mais perto, a Ponte Vasco da Gama (2 meses antes do prazo). Mas estes não são fenómenos que se repitam com facilidade.

Assim, é legítimo perguntar se não somos capazes de fazer melhor, considerando as ferramentas que agora possuímos. A chave é, parece-me, que a gestão de programas e de projectos são tratadas como campos técnicos quando deviam ser olhadas como jogos, visto que os resultados são consequência de decisões tomadas por diversos agentes independentes.

Na gestão de projecto decompõe-se um projecto em actividades mais pequenas, às quais se atribuem durações, recursos e constrangimentos de tempo e de precedência. De seguida são realizados cálculos que produzem gráficos de Gantt, são identificados os perfis para os recursos, o caminho crítico, etc. A ferramenta mais comum é aquela que permite realizar o Método do Caminho Crítico (todas as ferramentas no mercado). Recentemente, chegou Eli Goldrath com a sua Cadeia Crítica da Gestão de Projecto (Critical Chain) que se foca nos recursos ou a Matriz de Desenho da Estrutura (Design Strucuture Matrix) que visa gerir as interacções entre as actividades.

Estes são todos modelos consistente e muito bons para as apresentações de soluções, mas estão muito longe do dia-a-dia da gestão de projecto dirigindo-se muito mais ao primitivo processo de listas de itens de acção. O problema mais óbvio com o uso destas ferramentas é que a duração para as actividades elementares é desconhecida e nunca vi uma organização que realizasse um esforço sério para recolher estes dados.

Uma actividade de projecto não é como uma actividade de montagem fabril que possa ser cronometrada ou registada em vídeo. O trabalho de projecto nunca é completamente repetitivo, se repetimos sempre a mesma acção, então é chamado produção ou transacção, mas não um projecto. Como nunca fizemos esta actividade de projecto antes, não pode dizer quanto tempo levará, mas pode obter outra informação dos seus componentes e pode estimar as similaridades ou as diferenças, com as actividades que já realizou antes, se mantém um registo disso. O trabalho de engenharia é organizado por projecto e o tempo dos engenheiros é controlado por timesheets, mas estas folhas são preenchidas após os factos pelos próprios engenheiros sem rigor efectivos e não são exactas.

Há formas de estimar melhor o trabalho das actividades, mas esse não é a preocupação principal dos gestores de projecto, ao contrário, o seu pensamento está focado em frases que começam com «Nada mais interessa, se…». Inicialmente, um gestor encarregado de liderar o projecto criou um plano que deve ser aprovado e nada mais interessa. O propósito do plano não é assim estimação mas sim persuasão. Como é que isto será realizado? Não há uma forma directa de o dizer, porque obviamente depende de quem deve ser persuadido. O que é constante é que o gestor de projecto está a vender, e irá fazer tudo o que for necessário para fechar o negócio.

quarta-feira, novembro 30, 2011

O Desafio dos Projectos Internacionais

O mundo de trabalho contraiu-se significativamente nos últimos 20 anos e agora é muito comum trabalhar com parceiros internacionais em projectos. Isto pode ser um projecto de transformação, ou parte de um acordo de outsourcing, ou num modelo de offshoring, que é mais comum nas organizações que exigem processamento de transações em «follow the sun». Claro, que a companhia pode também ter divisões espalhadas por todo o mundo já que os projectos internacionais nem sempre envolvem terceiras partes, antes correspondem a projectos contratados.songdo_city
Para gestores de projecto isto significa que estarão envolvidos com diferentes tipos de stakeholders em projectos. Gerir projectos internacionais pode ser muito interessante e recompensador, mas estes projectos são também um grande desafio. Há algumas questões importantes a ter em conta em projectos internacionais.

A Língua

Pode parecer óbvio mas se está a trabalhar fora do paìs é muito pouco provável que toda a sua equipa de projecto fale a mesma língua. Estamos habituados a trabalhar em Angola, Moçambique, Brasil e mesmo aì há diferenças que devem ser explicadas. O problema com uma língua comum é muito maior se estiver a trabalhar com colegas que não trabalham regularmente na sua língua.
No início de um projecto vale a pena especificar qual vai ser a principal língua de trabalho do projecto. Em projectos fiderados a partir de um país de língua inglesa ou de uma companhia também de língua inglesa, isto naõ significa ser a língua inglesa para tudo. A ferramenta de gestão de projecto até pode ter interfaces em várias línguas. A equipa no local pode introduzir os dados de produção com menus na sua língua mas mantendo a língua oficial do projecto.
Respeite os membros da equipa que não estão a trabalhar na sua língua nativa. Minimize o calão ou os termos técnicos adaptados e faça com que a sua escrita seja falada e escrita de forma clara.

O Tempo

As diferentes culturas têm diferentes interpretações sobre o tempo e, para algumas, as milestones são só um guia. Podemos valorizar a pontualidade, mas outros membros da equipa podem não ter a mesma opinião sobre a hora de começar uma reunião. A única forma de gerir isto é ter uma conversa franca com todas as pessoas envolvidas, explicando os desafios potenciais e pedindo a colaboração para os enfrentar. É melhor ter sempre esta conversa o mais cedo possível do que perder muito tempo em esperas para reuniões ou chamadas telefónicas.

Funções e Responsabilidades

A função do gestor de projecto pode ser muito respeitada no seu paìs, mas o seu trabalho pode não ser compreendido noutros lugares. Os seus colegas noutros paìses onde a companhia tem estruturas podem não receber direcções porque podem não o ver (ou à sua função) como muito importante. Igualmente, podem não ter recebido suficiente orientação acerca de como as suas responsabilidades de projecto se enquadram com a sua função e a deles relativamente à sua.
Este desafio vai ser descoberto tarde, infelizmente, e já bem depois de ter começado a trabalhar no projecto e, assim, o seu plano de acção para isto será enfrentar um problema que já ocorreu. Fale com as pessoas e colegas que já tiveram a mesma experiência em trabalhos internacionais. Pode ainda envolver os gestores locais que podem ajudar a definir com as suas equipas as expectativas acerca do projecto, as funções deles e o papel do gestor de projecto relativamente a elas.

Ferramentas

Faça o máximo com o software disponível para si. Use o melhor software de gestão que puder usar e que possa suscitar a colaboração e compreensão da equipa relativamente ao projecto.
Algumas ferramentas têm capcidades de menssagem instantãnea, como por exemplo o Skype. Este tipo de tecnologia significa que pode estar ligado aos membros da sua equipa mesmo quando eles não estão a trabalhar na mesma sala. Mas elas servem melhor quando a diferença horária não é maior que um par de horas.
As ferramentas como blogues e wikis que permitem trabalho assíncromo são valiosas nas situações em que as diferenças horárias são muito grandes. Pode ainda registar apresentações ou ‘conference calls’ e torná-las disponíveis mais tarde. Pense criativamente sobre os problemas que tem e que precisa de resolver e utilize de forma adequada a tecnologia.

Equipas virtuais

A gestão de equipas virtuais é difícil e exige muito compromisso de todos os envolvidos. Tem de ser muito melhor na documentação, na partilha de conhecimento e na construção da equipa, do que quando tem tudo e todos estão na mesma sala. Estar atento aos desafios das equipas virtuais é o primeiro passo para identificar os métodos que o irão a manter a si e à equipa no caminho certo.
Temos todos de aprender muito com culturas diferentes e trabalhar em equipas internacionais pode ser uma das mais recompensadoras experiência da gestão de projecto. Quando olhamos os benefícios de trabalhar em projectos internacionais, estes desafios de que falámos são só uma parte da rica experiência que resulta de um ambiente de trabalho que se amplia e é global.
Luís Quintino

domingo, novembro 27, 2011

Indicadores Chave de Perfomance de Projecto

Alguns KPI que podem ser usados para provar o valor do PMO e demonstrar a sua efectividade.

Tempo para o Mercado

  • Tempo para o Mercado = tempo passado desde a concepção da Ideia até à Realização
  • Tempo para o Mercado Alternativo = Tempo de Realização Real – Tempo Planeado para a Realização

O PMO pode melhorar o tempo para o mercado do produto de duas formas. Primeiro, pode aumentar a velocidade à qual cada um dos projectos é concluído. Os benefícios disto são óbvios, já que um projecto que é concluído mais rapidamente geralmente significa maior satisfação do cliente e da companhia porque estará disponível mais cedo. O PMO também melhora o tempo para o mercado ao promover uma melhor aderência aos planos do projecto. Ao fazer isto promove a satisfação do cliente, melhora a confiança na equipa do projecto e oferece uma melhor capacidade de previsão do futuro dos ciclos de vida futuros do projecto.

Mas ainda mais importante, isto irá garantir que um produto dependente de tempo não irá falhar o seu prazo, por razões inerentes ao projecto, para não reduzir ou fracassar no seu sucesso. Os PMO que de forma consistente melhoram o tempo para o mercado podem melhorar os seus processos e ser desenvolvidos bem e mais rapidamente.

Disponibilidade de Serviço

  • Disponibilidade de serviço = Data Real de Início – Data Óptima de Início

A disponibilidade de serviço refere-se ao tempo que leva a iniciar um projecto em comparação com a data desejada de início. Difere do tempo para o mercado de duas formas: primeiro, pode medir o tempo que é atribuído a actividades específicas em oposição a só se referir a data de conclusão de um produto e, segundo, pode ser medido em numerodos pontos durante o desenvolvimento do projecto. Como ponto de referência para o negócio, faz sentido porque mede a capacidade de concluir mais projectos ou alocar mais tempo a projectos propostos. Paar além disso, quando o PMO possui uma boa medida de disponibilidade de serviço está em posição para redireccionar recurso para actividades no caminho crítico se for necessário. O PMO especiliza-se na disponibilidade de serviço através de standardização de actividade e planeamento de futuros projectos.

Se a equação acima tem um número mais baixo isso significa maior disponibilidade de serviço. Contudo, uma companhia deve ser cuidadosa para não ter tal quantidade de disponibilidade porque isso significa que tem recursos desperdiçados. Isto pode desbaratar tanto dinheiro como o que é desperdiçado num plano mal feito e mal gerido.

ROI

  • ROI = (Rendimento – Investimento) / Investimento * 100

O PMO contribui para o ROI da companhia assegurando-se que os projectos são concluídos com sucesso e de acordo com as especificações definidas pelo cliente e stakeholders. Por isto, examinar o ROI como um KPI oferece uma vista incompleta à produtividade do PMO. Porque o PMO não influencia directamente o retorno financeiro. Antes oferece a estrutura através da qual poderemos construir o sucesso. O ROI, então, deve ser examinado em combinação com outras métricas para determinar a influência específica do PMO na performance global do negócio da companhia. O ROI pode ser usado para medir o sucesso, mas deve ser olhado projecto a projecto para determinar o impacto real do PMO.

Crescimento das Vendas

  • Crescimento das Vendas = (Vendas correntes – Vendas anteriores)/Vendas anteriores

O PMO contribui para o crescimento das vendas de forma muito semelhante à sua influência no ROI. Faz isso oferecendo um ambiente que permite o crescimento das vendas sem muito esforço, muitas vezes através da melhoria das métricas nesta lista, como tempo para o mercado e disponibilidade de serviço. No entanto, a medida do crescimento das vendas não especifica a função do PMO nessa melhoria. Entretanto, melhorar o crescimento das vendas irá ser muito atractivo para os executivos de alto nível e, em particular, os CFO, porque é aquilo que os accionistas e investidores procuram numa companhia. Como tal, e apesar das óbvias limitações, o crescimento das vendas é uma métrica importante porque uma melhoria nesta área vai criar mais oportunidades financeiras para o negócio e poderá convencer muitos descrentes no PMO.

Utilização do Serviço

  • Utilização do Serviço = Horas Facturadas/Horas Totais

Para além de reduzir e standardizar as actividades através do crescimento da disponibilidade do serviço, a utilização do serviço permite ao PMO garantir que o tempo está a ser usado com eficiência. Aqui, a utilização do serviço significa analisar os recursos alocados a um projecto e em particular os recursos humanos. Um PMO avançado será não só capaz de diminuir o número de pessoas que estão sobre e subutilizadas, mas será capaz de atribuir as pessoas para as actividades para as quais são os melhores, desta forma maximizando ovalor do seu tempo.

Aumentar a qualidade da utilização do serviço significa uma melhor qualidade do resultado do projecto na mesma quantidade de tempo. Isto irá optimizar a satisfação do cliente e dos empregados e irá garantir que o negócio está ao obter o melhor valor dos seus recursos e trabalho contratado.

______________

Demonstrar melhoria nestes KPI pode ajudar a mostrar o sucesso de um PMO da companhia. Em conclusão, o PMO ainda não foi aceite como necessário na maioria das organizações e é assim responsabilidade dele comprovar o valor que oferece. Deve repetir-se, contudo, que como o PMO é único, estes KPI devem ser olhados deforma específica para a companhia.

sábado, novembro 26, 2011

PMO e Métricas para o Sucesso

O Project Management Office (PMO) é a estrutura orgânica / função com a capacidade de instituir numa organização uma ampla e variado conjunto de mudanças positivas. De facto, e ainda bem, em muitas organizações no mundo compreendem a co-dependência entre o executivo e o PMO e agem para estabelecer os PMOs e justificam-nos por essa mesma razão.

Infelizmente, é muitas vezes uma das partes mais incorrectamente gerida e sub-utilizada em algumas partes importantes. A Gartner, importante firma de consultoria, apresentou as conclusões de um estudo em que indica que quase metade dos PMO acaba em fracasso. A questão, então, é porque é que um número tão elevado de companhias sente que os seus PMO não realizam valor?space

Há algumas respostas que devem ser exploradas, mas devido à natureza muito individual de cada PMO, é difícil ter uma lista definitiva de pontos de falha. Contudo, uma questão que atravessa quase todos os PMO tem a ver com as métricas. Demasiados PMOs não medem o seu sucesso com os adequados Indicadores Chave de Performance (KPI, como ouvimos falar com o uso do acrónimo do inglês). Devido a este fracasso, os executivos de alto nível podem com facilidade questionar o valor do PMO, particularmente o Administrador Financeiro (CFO) dirigido sempre por resultados.

O PMO, com o seu empenho em medir o processo e os protocolos, pode falhar no foco que deve ter nos KPI relevantes para o progresso global do negócio. Por efeito deste fracasso em documentar devidamente o seu sucesso, muitos PMO que antes foram produtivos estão a ser encerrados.

A lista seguinte de KPI potencialmente importantes pelos quais um PMO pode medir a sua produtividade no contexto do sucesso global da companhia. Esta lista baseia-se num estudo conduzido pelo Center for Business Practices e documentada no livro "Justifying the Value of Project Management". Julgo que estes KPI específicos são relevantes para as administrações e já provaram que melhoram as práticas de gestão de projecto.

Mas é importante, em primeiro lugar, relembrar duas coisas. Primeiro, o papel do PMO é (e será sempre) muito específico para as necessidades da Companhia em questão. Não se deve procurar aplicar estes KPI directamente. Ao contrário, eles devem adaptados para reflectirem o papel desempenhado pelo PMO. Segundo, demasiados KPI podem conduzir para uma percepção escondida da realização real do sucesso ou do fracasso.

Como se tivéssemos muitos indicadores no painel de instrumentos de um carro o que leva a que a medida seja arriscada e confusa. É sempre melhor pegar num par de KPI que se adaptam bem à companhia e focar a atenção naqueles em vez de medir uma quantidade elevada de indicadores que irão trazer resultados contraditórios.

terça-feira, novembro 22, 2011

Para que serve a Timesheet?

As Razões pelas quais os Gestores de Projecto devem Acompanhar a Duração

Nos escritórios por todo o mundo, as sextas-feiras à tarde são tempo de status e timesheets. Toda a gente desde as equipas técnicas aos gestores de projecto tem queixas acerca do sobre trabalho administrativo que implica o preenchimento das timesheets. Alguém em algum lado durante a corrente semana realizou trabalho que agora não aparece na timesheet e tem de se perguntar onde atribuir essas horas perdidas. E pode ter a certeza que alguns acreditam que todo este exercício de timesheet é exigido só por que a «gestão» não acredita que os trabalhadores consigam concluir o trabalho.

Apesar de tudo o que tem a ver com os registos de tempo, logo que as pessoas compreendem a melhor forma de o fazer de maneira a levar o menor tempo possível por semana, consegue-se geralmente obter um bom nível de adopção pelos empregados. Mas por que é isto útil? Por, pelo menos cinco razões.

Melhora a tomada de decisões

Tempo é dinheiro. Se sabe onde é que os seus empregados estão a gastar a maioria do tempo, tomará mais facilmente decisões acerca de como fazer poupanças ou em como realizar mais rápido. Por exemplo, se o tempo de viagem é consistentemente alto num projecto, pode ser apropriado analisar outras opções que estejam disponíveis em vez de ter pessoas valiosas e altamente pagas em viagem em vez de se focarem nos requisitos do seu trabalho.

Ajuda na atribuição de recursos

As ferramentas de gestão empresarial de projecto tornam fácil registar em que é que as pessoas estão a trabalhar e quais os projectos que estão no portfólio. Se pusermos os dois em conjunto verificamos que uma ferramenta empresarial pode mostrar quais os recursos que são necessários para os projectos em imediatos. Conhecer quais os requisitos do trabalho dos próximos projectos significa que se pode identificar quem estará livre para os concretizar.

Podemos até simular os recursos para definir o que poderá acontecer se se tirar alguém tirar alguém mais cedo de um projecto para realizar algum trabalho nestes projectos. A capacidade de simular com os recursos mostra as várias diferentes opções e permite seleccionar as mais apropriadas para cada situação.

Favorece a comunicação

As pessoas resmungam contra as timesheets, mas os dados que elas oferecem oferece um bom ponto de discussão. Saberá em que é que as pessoas estão a trabalhar e se elas estão a fazê-lo da forma correcta para usarem o seu tempo. Debaixo deste foco é mais difícil esconder os projectos. Não será preciso encontrar uma desculpa para falar à equipa de projecto, mas as timesheets dão sempre uma boa. Reveja com eles o tempo gasto no projecto e peça sugestões acerca de áreas que podem ser melhoradas.

As previsões são mais acertadas

É muito difícil justificar que esteja quase a terminar numa actividade em que mesmo agora se mudou a previsão para permitir atribuir-lhe mais 20 horas. É fácil ao gestor de projecto ver quanto trabalho exactamente ainda tem de ser feito. Esta informação é de enorme valor para o plano do projecto e para a previsão do que vai acontecer durante o resto do projecto.

As estimativas têm mais significado

Para além de permitirem olhar para a frente com propósitos de previsão, as timesheet também permitem olhar para trás. Quanto tempo levámos a fazer os testes da outra vez? Será possível ter informação até à hora mais aproximada. Esta é informação realmente útil para quem tem de planear. As estimativas do trabalho futuro podem ser informadas e melhoradas com exemplos reais de como estas actividades forma realizadas no passado.

O registo de tempo pode ser um assunto desagradável para falar com a equipa, mas as ferramentas tornam fácil integrar este nos métodos de gestão de projecto. Quando possuir um registo robusto do tempo a funcionar e perceber a informação que consegue obter, vai querer para sempre com timesheets.

segunda-feira, novembro 14, 2011

Quanto tempo para implementar a ISO 27001

Esta é a segunda pergunta mais comum no que respeita à implementação da ISO 27001. A primeira é, evidentemente, «quanto é que vai custar?». Bem, mas a resposta não é muito encorajante – porque a maioria das pessoas acha que se faz num par de meses. Só que isto não é realista – a duração mais aproximada se tudo correr bem é: cerca de 1 ano.

Claro que se pode continuar a produzir 50 documentos com fluxos, regras e normas em alguns dias e reclamar que temos regras em conformidade com a norma ISO 27001, mas isto não é aquilo que importa. O que queremos falar é sobre a implementação que faz sentido, que produz resultados – um menor número de incidentes, crescimento da eficiência, poupança de custos, etc.image

Tempo para as fases de PLANEAR e FAZER

O esforço principal da implementação será gasto nas fases de Planear e fazer, ou seja, nas primeiras fases mandatórias nas quais são realizadas a avaliação de risco e análise de impacto no negócio e nas quais todos os controlos (incluindo os planos da continuidade do negócio) são implementados. A duração para estas duas fases depende, em primeiro lugar, da dimensão da organização.

  • Organizações mais pequenas (até 50 colaboradores) normalmente implementam o standard em 8 meses.
  • Organizações médias (até 500 colaboradores) implementam o standard de 8 a 12 meses.
  • Organizações grandes (mais de 500 colaboradores) a implementação leva de 12 a 15 meses.

As companhias que arrastam estes projectos demasiado tempo, não conseguem terminar – em tais organizações nunca há suficiente reconhecimento da importância do standard, e assim os recursos financeiros e humanos dedicados ao projecto nunca são suficientes.

Quando falamos de tempo de implementação é importante referir que o trabalho de implementação da ISO 77001 e da ISO 25999 não termina com as fases Planear e Fazer – estes sistemas de gestão necessitam ser mantidos e melhorados (fases Verificar e Agir), o que significa que o trabalho na segurança da informação e na continuidade de negócio não é uma vez mas sim contínuo. Contudo, o esforço para manter e melhorar o sistema de gestão é bem menor que o necessário nas duas primeiras fases.

As coisas que aceleram a implementação

A duração que referimos acima depende de muitos factores, mas geralmente os seguintes factores irão acelerar a implementação:

Realizar a implementação como um projecto – se souber com exactidão quais são os objectivos, quem é o responsável e por quê, se os recursos estiverem dispo níveis e quais são os resultados, não só irá acelerar o processo, mas também aumentará as usas oportunidades de sucesso.

Se já tiver a ISO 9001 ou outro sistema de gestão – os standards não são diferentes de outros sistemas de gestão, o que permite utilizar alguns dos procedimentos e processo existentes e poupar entre 20 a 30% de tempo.

Se já possuir a funcionar muitos dos procedimentos e políticas de segurança / continuidade de negócio – a oportunidade de que a documentação existente seja aceitável para a ISO 27001/25999 irá reduzir o tempo de implementação; também por que já possui na organização uma compreensão acerca da segurança da informação e continuidade de negócio.

Possuir os modelos de documentação adequados – não quero dizer quaisquer modelos de documentação, mas modelos na própria língua, apropriados para a dimensão da companhia e feitos para o propósito das ISO 27001 e 25999. Os modelos livres da internet obrigam à tradução e adaptação, com frequentes revisões.

Possuir o conhecimento – este pode obter-se através da leitura, formação pessoal, cursos online, ou pela contratação de um consultor; sem o conhecimento o seu projecto irá levar mais tempo, e provavelmente nunca será concluído.

A última mas certamente a primeira – o apoio e compromisso da gestão – se este não for obtido e se não for comprometido efectivamente em recursos e em dinheiro, o projecto irá demorar mais ou será concluído mesmo antes de começar.

Em conclusão – a implementação de standards com o estes toma muito tempo o que força a que se faça com este propósito em mente. Se a implementação for realizada de forma superficial ou sem objectivos claros, não irá somente perder uma quantidade de tempo mas também perder uma oportunidade para ajudar a companhia a melhorar e a crescer.

LQ

quinta-feira, novembro 03, 2011

O Controlo da Mudança

Continuamos hoje a falar do processo de controlo da mudança e a esclarecer como se pode implementar o processo com simplicidade.

O controlo de mudanças é uma parte importante do processo de gestão de projecto. No caso da Engenharia e Construção quase que podia afirmar que ninguém implementa um processo formal e piro ainda, as mudanças são muitas vezes utilizadas para resolver a má estimação inicial do contrato. changes

Mas, com o ritmo de mudança nos nossos dias é mais do que certo que os projectos enfrentam exigências de mudança durante a sua vida. Muito embora a mudança possa ajudar a assegurar que os projectos estão alinhados com as necessidades de negócio, é importante ter em conta que cada mudança deve ser cuidadosamente considerada e aprovada. Daí que o processo mesmo que deforma elementar deve ser criado na equipa de projecto.

O processo de controlo da mudança na gestão de projecto garante que todas as mudanças propostas durante o projecto são devidamente definidas, consideradas e aprovadas antes da implementação. Isto garante que nenhumas mudanças desnecessárias sejam realizadas e, assim, os serviços não são interrompidos e os recursos são eficientemente usados. Se isto não são benefícios importantes então pensem o que será se o processo não for implementado.

O processo de controlo da mudança contém 5 passos:

  1. Propor uma mudança
  2. Sumário do impacto
  3. Decisão
  4. Implementar a mudança
  5. Fechar a mudança

Durante o processo são utilizados dois documentos:

  1. Registo das mudanças: usado para registar todas as mudanças pedidas e decisões tomadas
  2. Formulário de Registo de Mudanças: usado para documentar os detalhes da mudança, incluindo o seu business case.

Propor uma mudança

O processo, pensado desta maneira, oferece a capacidade de qualquer pessoa na equipa do projecto 8 mas incluindo o cliente) propor uma mudança ao projecto. A proposta deve incluir uma descrição da mudança e os benefícios esperados ou outra razão justificativa da mudança. A mudança é apresentada usando o Formulário de Pedido de Mudança e adicionada ao Registo de Mudanças do projecto.

Sumário do Impacto

O projecto é conduzido pelo Gestor do Projecto que irá considerar o impacto da mudança no projecto. Serão consideradas as seguintes questões:

  • Custo quantificável de poupanças ou benefícios
  • Razão para a mudança legal, regulatória ou outra
  • Custo estimado da mudança
  • Impacto na escala de tempo do projecto
  • Recursos adicionais necessários
  • Impacto em outros projectos ou actividades de negócio
  • Novos riscos ou questões

Depois desta avaliação, o gestor de projecto recomenda se irá ser desencadeada a mudança.

Decisão

Este processo envolve a revisão do pedido de mudança por uma autoridade definida que irá considerar toda a informação obtida por quem fez o pedido e a avaliação de impacto do Gestor de Projecto. A decisão será usualmente:

  • Aceitar
  • Aceitar com comentários ou condições especiais
  • Rejeitar
  • Deferir (a mudança não é aprovada, mas poderá ser considerada mais tarde)

Implementar a Mudança

Se a mudança é aprovada esta será planeada, calendarizada e implementada na data acordada com os stakeholders.

Como parte do planeamento, deve ser elaborado um plano de regressão para o caso em que se deva recuar da mudança.

Depois da implementação é habitual levar a cabo uma revisão pós-implementação.

Fechar a Mudança

Quando o responsável pelo pedido de mudança dá o seu acordo a que a implementação foi correctamente realizada, a mudança é fechada e registada no Registo de Mudanças.

segunda-feira, outubro 24, 2011

Controlar os pedidos de Alteração nos projectos

Os pedidos de alteração quando um projecto se inicia são uma parte inevitável do projecto. Elas podem ser o resultado de mudanças externas no negócio ou podem ser mudanças internas requeridas porque os propósitos originais do projecto não foram claramente definidos ou compreendidos. IMG00302

As mudanças requeridas por factores externos estão normalmente fora do controlo de um gestor de projecto e há muitas vezes poucas escolhas para as enfrentar. Muitos dos gestores de projecto experimentados terão já colocado em posição um processo no início do projecto para tratar destes pedidos e o plano será suficientemente flexível para tratar delas sem afectar o resultado final.

Mas os pedidos de alteração provenientes de factores internos devem ser tratados de forma muito diferente. Num projecto ideal muitos destes devem ser evitados garantindo que os objectivos do projecto estão bem definidos, que os requisitos estão documentados claramente, que foram comunicados a todos os stakeholders e que estes compreenderam o que é esperado do produto final. Claro que nós não vivemos num mundo ideal e por mais profunda e bem detalhada que sejam as fases iniciais do projecto tem de existir em posição um efectivo processo de controlo da mudança.

Nem todos os stakeholders e utilizadores conseguem visualizar o produto final pela leitura da documentação e estudo de diagramas. Mesmo quando são usados protótipos para melhorar a produção de requisitos, estes são, pela sua própria natureza, produtos não inteiramente funcionais e serão inevitáveis incompreensões e assumpções nos projectos complexos.

De qualquer forma, a boa documentação e documentação clara dos objectivos e requisitos de projecto irão minimizar o número de pedidos de alteração.

Então qual é a melhor forma de controlar os pedidos de alterações num projecto e continuar a realizar a conclusão do projecto dentro de um orçamento, de escalas de tempo e âmbito?

Distinguir entre o Necessário e o «Era bom ter»

Cada um dos pedidos de alteração deve ter uma justificação (que tal um «business case») que os suporte, tal como o projecto tem uma justificação. Claro, que esta justificação pode ser muito simples e breve, mas é um elemento necessário de todos os pedidos de alteração antes que possam ser considerados para inclusão no projecto.

O elemento mais importante deste «business case» do pedido de alteração é o benefício esperado o qual deverá indicar o valor que será adicionado ao projecto pela mudança. Isto indicará, por si próprio, quais as mudanças que serão provavelmente necessárias. É importante reconhecer que a descrição de alguns destes «business cases» pode não beneficiar necessariamente o projecto em termos de tempo e orçamento, mas sejam necessárias para que o cliente se mantenha competitivo no mercado.

Se os benefícios não forem especificamente declarados então deve discutir-se a questão com a pessoa que requereu a alteração para determinar se existe um genuíno benefício de negócio.

Soluções melhor desenhadas, ou mais bonitas, com funcionalidades e mais atractivas não são benefícios a não ser que possam ser apoiadas pela forma como estas tiveram um impacto positivo no orçamento e no plano do projecto, ou, um impacto positivo nos esforços dos utilizadores em completarem actividades regulares. As perguntas mais vulgares a que deve responder o «business case» são:

  • · Qual é a mudança externa no negócio de que resultou este pedido de alteração?
  • · Quais os factores internos de que resultou este pedido de alteração?
  • · Como é que esta mudança irá afectar o tempo que levamos a completar o projecto?
  • · Como irá esta mudança afectar o produto final para o utilizador?
  • · Que poupanças serão realizadas pela implementação desta mudança?

Evite desperdiçar Tempo e Esforço

A forma mais óbvia de evitar desperdiçar recursos valiosos de projecto em pedidos de alteração excessivos e em todo o processo de gestão da mudança, é garantir que o projecto se inicia com objectivos e requisitos claramente definidos. É também importante o critério que iremos usar para determinar o sucesso do projecto estar documentado sucintamente desde o início do projecto. Deve garantir que estes documentos são distribuídos aos stakeholders e utilizadores e que estão acessíveis cópias dos documentos.

Planeie actividades incluídas no plano do projecto para tratar dos pedidos de alterações e se este tempo foi ocupado adie os pedidos importantes para a próxima semana. Garanta que todas as partes interessadas sabem como trabalha este processo.

Tenha um Critério Claro de Aceitação e Rejeição

Defina um critério para avaliar estes pedidos que não serão, ou não poderão ser implementados. Quem faz o pedido tem de compreender o critério e este tem de ser consequente. O critério essencial, como já vimos, é ter uma justificação escrita, um «business case», que esclareça os benefícios. Se não tiver pode ser de imediato devolvido a quem emitiu o pedido. Não perca tempo atrás de quem fez o pedido para saber qual é a justificação escrita. A responsabilidade disso é de quem faz o pedido que o deve fazer logo desde o início (mesmo que depois devamos discutir e aprofundar a discussão sobre esta justificação).

Esteja preparado para fundamentar as razões para rejeitar um pedido de alteração com uma descrição bem pensada do porquê para não incluir a mudança. Mantenha-se na sua decisão a não ser que o sponsor do projecto queira aumentar o orçamento ou o tempo disponível no projecto.

Esteja, também, preparado para ser flexível e para negociar a substituição de uma actividade em favor da mudança quando não há nem orçamento nem tempo disponível.

Aplique sempre as melhores práticas de gestão de projecto em todas as áreas do projecto se quer aumentar as suas oportunidades de sucesso.

terça-feira, setembro 20, 2011

O Risco, uma técnica simples

Todos os projectos são diferentes e a melhor forma de identificar os potenciais riscos dentro de projectos complexos é recorrer à experiência de projectos passados dentro da mesma área. Mesmo com indústrias diferentes há muitas áreas de risco potencial que podem ser as mesmas ou similares, existindo obviamente áreas específicas.
A primeira abordagem é obter uma visão global das diferentes áreas do projecto tais como:
  • Âmbito
  • Equipamento
  • Tecnologia
  • Pessoas
  • Escala de tempo
  • Orçamento
Em seguida, escolha cada uma destas secções e decomponha-a com mais detalhe. Pode ser útil uma sessão de brainstorming com um pequeno grupo de membros da equipa em representação de diferentes partes dos departamentos e grupos envolvidos. Não deve ser uma actividade que consuma muito tempo, mas é crítica para a gestão com sucesso do projecto.quem_e_o_culpado

Âmbito

A natureza do âmbito é a definição do que é e do que não é incluído nos requisitos que o negócio pretende obter. Assim, as áreas que podem correr mal ou causar problemas serão questões que terão a ver com o que é e não é escrito neste documento ou que não foi suficientemente descrito nos documentos do projecto. Os primeiros riscos identificados podem ser «requisitos de negócio pobremente definidos», «falta de pessoal experimentado» ou «requisitos de negócio que não foram aprovados pelo cliente».

Equipamento

Esta área de foco deve incluir o equipamento requerido para concluir o projecto em vez de qualquer equipamento que seja uma entrega ou um resultado final do projecto. Pode incluir hardware de computadores, equipamento fabril para a realização do produto final ou um conjunto de outras possibilidades dependentes do projecto particular. Ao identificar os riscos nesta secção deveremos considerar riscos como «confiança do equipamento», «facilidade de substituição se avariar», «custos da substituição do equipamento avariado».

Tecnologia

Esta secção cobre todas as áreas que tenham a ver com o uso de computadores excepto o hardware físico e outras áreas de inovação ou de desenvolvimento envolvidas no projecto. Deve ter-se atenção às dependências com pacotes de software (quer internos como externos) e sistemas de gestão de bases de dados, com outros fornecedores de tecnologia a usar no projecto.

Pessoas

Até que ponto são críticas as pessoas existentes para o sucesso do projecto. Eles possuem conhecimentos especializados que podem ser difícil ou muito dispendioso obter em outro lado. Deve enfrentar-se também a possibilidade de haver uma grande mobilidade das pessoas ou, ao contrário, as equipas estão bem motivadas e estabelecidas e irão permanecer durante o decurso do projecto. Se for o caso de ser gestor de um projecto grande e global, pode até ocorrer que não conheças as equipas em localizações diversas e só tenha contacto com gestores de projecto locais. O conhecimento sobre a dinâmica e construção das equipas pode ser muito útil para a avaliação de riscos potenciais.

Escala de Tempo

Os primeiros problemas têm a ver com o detalhe e correcção das estimações efectuadas para todo o projecto e cada actividade individual. Se o projecto for qualquer coisa diferente de tudo o que fez antes, serão as estimativas meras adivinhas? Quando as escalas de tempo foram determinados por um imperativo de negócio por virtude uma data determinada pelo mercado são acrescentados novos factores de risco no agendamento. Todos estes factores afectam o tipo e a probabilidade dos riscos para as escalas de tempo do projecto.

Orçamento

Se o orçamento foi determinado por um imperativo do cliente em vez do custo real pode não oferecer os meios para concluir o projecto. Um orçamento limitado, por outro lado, não é necessariamente uma causa de insucesso para o projecto. Um bom gestor de projecto possuirá as competências requeridas para obter o máximo de um orçamento limitado e minimizar também os riscos dentro de um projecto deste tipo.

Em geral

De facto muitos factores que gestores de projecto menos experientes podem pensar que criam um projecto mais «arriscado» são muitas vezes factores que podem ser facilmente geridos porque ocorrem frequentemente, como ó caso de recursos limitados, escalas de tempo apertados ou orçamento limitado. É mais provável que o risco provenha de factores que ocorrem com menos frequência como tecnologia ainda não totalmente testada ou produtos, e estes podem tirar um projecto do seu curso.
Desta forma, a identificação dos riscos num projecto é crítica para os gerir com sucesso e estas áreas que, em breve, descrevemos são as mais importantes para o gestor do projecto considerar ao identificar os riscos. Para projectos maiores e mais complexos, a gestão de risco será um trabalho a tempo inteiro e exige que o gestor de projecto tenha a formação e as competências para o assumir com efectividade
.










sexta-feira, agosto 12, 2011

Recuperar o Controlo do Projecto

Um projecto que está fora de controlo, quer devido a um orçamento ultrapassado seja quanto a desvio no planeamento, não vai voltar ao caminho sem um esforço sério e um compromisso por parte das pessoas envolvidas no projecto e de parte da organização que o realiza. Felizmente existem três processos simples e cumulativos para ajudar o gestor do projecto a recuperar o controlo e a resgatá-lo do fracasso.

1. Determinar o estado actual do projecto

Revisão de todas as tarefas e actividades para que se possa determinar exactamente onde o projecto está em relação com o cronograma e o orçamento real. Ignore qualquer custo estimado anteriormente e os tempos definidos e concentre-se em determinar o status real.

Deve rever todos os relatórios disponíveis e falar com os membros da equipe para explicar o que quer saber exactamente, qual o progresso que tem sido feito, independentemente de qualquer estimativa anterior, promessas ou compromissos. É fundamental para controlar a recuperação do projecto que você possa começar a partir de uma base conhecida. Dessa forma, o replaneamento tem a melhor possibilidade de sucesso e pode, com esperança e trabalho, evitar que o projecto se transforme num desastre.songdo_city
Se não tentar determinar e documentar todas as hipóteses, as óbvias e as não tão óbvias nas fases iniciais do projecto, agora é o tempo de fazê-lo. É vital ser persistente e garantir que todas as premissas são conhecidas e documentadas.
Deve não apenas reavaliar o status do projecto em termos de tempo e orçamento, mas também reavaliar os recursos disponíveis em termos de competências e pessoas. Se não levar isso em conta no replaneamento e reagendamento não vai garantir que todos saibam o que você pretende para que o projecto seja um sucesso.

2. Reafirmar o objectivo do projecto

Certamente que não foi uma miragem o que garantiu os compromissos com o projecto, o que obteve a garantia do financiamento e o que permitiu que o projecto arrancasse. É função do gestor de projecto lembrar agora às pessoas a visão original e tentar reacender algum do entusiasmo com que o projecto começou.

O objectivo de negócio deve ter sido claramente definido e documentado no início do projecto, mas se não foi esse o caso, então agora está na hora de corrigir esse problema específico. Irá assim ajudar as pessoas a relembrar os benefícios que o projecto na sua conclusão terá para eles, como indivíduos, bem como para a organização no seu conjunto.
Devem ser realizadas as acções que permitam envolver as pessoas no projecto e garantir que sabem a importância de cada actividade que completam, para o sucesso global do projecto. Inspirar a equipa e fazer que todos os elementos se sintam valorizados. Isto pode parecer banal, mas é realmente vital para garantir que o projecto permanece controlado e se conclui em sucesso.

3. Decidir como atingir o propósito do Projecto

Agora que já realizou uma avaliação exaustiva da situação do projecto no que diz respeito ao orçamento, ao cronograma, às pessoas e às suas competências. Você sabe que nesse processo comunicou e reforçou a visão do projecto e o objectivo de negócio a todos os participantes do projecto e especialmente aos membros da equipa.

O próximo passo é planear a abordagem que lhe permitirá, a partir do presente estado, alcançar a conclusão com sucesso do projecto.

Pode ser que, em primeiro lugar, alguns dos factores que têm retirado o projecto do seu curso ainda existam e, portanto, pode haver pouca razão para optimismo quando se trata de replaneamento para a finalização do projecto. Mas temos de planear – se necessário teremos de reavaliar o status do projecto e voltar a replanear dentro de algumas semanas ou meses. De qualquer forma para poder avançar é necessário realizar agora um plano total.

Em alguns sectores da indústria, tal como as TI, que estão rapidamente a mudar e que podem ter uma alta rotatividade de pessoal é praticamente impossível planear um projecto do início ao fim que não necessite de ser reavaliado e replaneado em vários estágios ao longo do projecto. Não deixe que o facto disto acontecer possa incutir um sentimento de fracasso na equipa. Em algumas indústrias isto é normal e um plano altamente detalhado é improvável que vá sem uma ligação com um programa mais complexo.

As finanças e outros recursos podem mudar durante a execiçoa de um longo projecto e ogestor de projecto tem que saber como recuperar o controlo de um projecto afectado por circunstâncias imprevistas. Tratar estas coisas como uma oportunidade para voltar a entusiasmar a equipa e lembrar a todos a visão inicial do projecto, em seguida, avançar para a conclusão em sucesso do projecto.

LQ

terça-feira, julho 05, 2011

O Essencial da Gestão de Projecto

Vou estar uns dias em África em consultoria de gestão de projecto e lembrei-me de relembrar o mais essencial na gestão de projectos. Não são técnicas, antes é a atenção para com coisas que não devemos esquecer.

Muito poucos planos de projecto são simples ou directos, porque têm sempre tantos factores contributivos que devem ser acautelados. Quais são exactamente todas as actividades que são requeridas e quanto tempo tomará cada actividade? Quais são as dependências entre as actividades? Algumas actividades podem exigir competências especializadas ou formação e empreiteiros podem ter de ser contratados para alguns aspectos do projecto. O esboço inicial pode não estar documentado de forma completa e problemas e omissões podem vir a revelar-se durante a etapa de planeamento. Pode ainda existir um prazo irrealista com que entramos em conflito.

São muitas questões que revelam uma pequena parte da complexidade do trabalho de um gestor de projecto.
 

Tempo e dinheiro

Os Gestores de Projecto podem sofrer enormes pressões para concluir o projecto dentro de um prazo fixo (deadline, que significa linha de morte), que foi estabelecido devido a factores fora do seu controlo. Pode ser pensaruma questão de marketing em que é crítico o tempo para o mercado de um novo produto: pode ser um requisito do investidor ou qualquer outra razão económica, social ou mesmo política. Qualquer que seja, é dever do gestor do projecto trabalhar em função desta. Mas o pior é quando é essencial encolher todas as actividades necessárias dentro do tempo agendado e não permitir nenhuma derrapagem.

É completamente irrealista pensar e esperar que não seja necessária nenhuma contingência no agendamento planeado de qualquer projecto, seja grande ou pequeno. Então o que que pode ser feito se todas as actividades requeridas não podem simplesmente ser realizadas dentro do tempo disponível? Mesmo assumindo que tem estimativas razoáveis para estas actividades (tenha a certeza que tem) então a melhor opção será negociar com os sponsors do projecto para escalar os requisitos quer pela remoção de alguns aspectos ou pela alteração dos resultados finais. É sempre melhor entregar um produto funcional sem dezenas de campainhas e assobios do que entregar um produto como milhares de funcionalidades mas sem cumprir de forma cabal a sua função básica.

Pesquisas realizadas entre pessoas afectadas pela conclusão de um novo produto realçam o facto de que os utilizadores estão normalmente só interessados no trabalho básico do produto porque o seu projecto últra-ambicioso então tem de negociar uma redução de funcionalidades do resultado final.

Garanta, assim, que há sempre alguma contingência de tempo incluída no seu plano e se o seu agendamento não aceita isto porque o projecto é demasiado ambicioso então deve negociar por uma redução das funcionalidades nos resultados finais. O mesmo aplica-se com o custo do projecto – mantenha-se dentro do orçamento reduzindo as funcionalidades em vez de criara atalhos e realizar um produto ou serviço de baixa qualidade.

Planear um projecto é equilibrar entre alta qualidade de um produto ou serviço no fim do projecto e uma atitude realista e responsável relativamente à escala de tempo e custos envolvidos. Estes dois aspectos não se excluem mutuamente e com as competências certas podem com muita efectividade ajustar-se no equilíbrio correcto.
 

Pessoas

Pode ter a sorte de, como gestor de projecto, poder seleccionar os membros da sua equipa, mas muitas vezes a equipa é aquela que lhe foi atribuída. Isto é particularmente verdadeiro quando o trabalho é atribuído a sub-empreiteiros ou parceiros.

Em qualquer dos casos o elemento chave que irá afectar todo o projecto e a sua capacidade de o gerir com eficiência é até que ponto estão motivados os membros da equipa. Para grandes projectos deverá poder nomear algumas pessoas, obter o seu compromisso com o projecto e garantir de forma contínua que o trabalho destes com os membros das equipas irá envolver todos no compromisso com o projecto.

Os gestores de projecto possuem diferentes competências, personalidades e métodos de trabalho e desta forma é difícil definir uma abordagem que venha a funcionar melhor do que outra. O factor chave para obter o compromisso por parte da equipa é alimentar a individualidade própria de cada membro da equipa. Isto significa referenciar quando foi feito um bom trabalho e elogiar por isso, interessar-se pelas suas preocupações ou problemas com o projecto e acompanhar as questões entre os diferentes membros da equipa como, por exemplo, choques de personalidade.

Pode pensar que isto não faz parte da função de um gestor de projecto, mas tente só assumir um interesse pessoal com os membros chave da equipa do seu próximo projecto e veja por sim próprio qual a diferença que tem a construção de uma equipa em que se valoriza cada um, em que se confia em cada um e se consegue trabalhar com um verdadeiro envolvimento.
 

Técnicas de Planeamento

Como em quase todas as áreas de negócio hoje, existem pacotes de software disponíveis para tornar mais fácil o trabalho do gestor de projecto. Contudo para os utilizar é essencial uma compreensão global dos princípios básicos do planeamento de projecto para obter mais do uso destas ferramentas. As ferramentas serão sempre aquilo que o trabalhado é.

Algumas das ferramentas frequentemente utilizadas em gestão de projecto são o Brainstorming, os Diagramas de Causa e Efeito, os Gantt Charts e a Análise do Caminho Crítico.

Tal como o brainstorming é uma técnica útil durante a análise de negócio e de levantamento de requisitos também pode ser muito útil na fase de planeamento para identificar as relações entre as actividades, para desenvolver ideias de eficiência ou de poupanças em custos e desperdícios, ou mesmo para levantar questões e destacar problemas potenciais.

Na etapa de planeamento os gráficos e diagramas são ferramentas úteis para visualizar todas as questões e mais ainda. Podem ajudar a clarificar os diferentes aspectos do plano e, em função do tipo de projecto , podem ainda servir por muitas outras e diferentes razões.

LQ

sexta-feira, junho 17, 2011

Planear um Projecto com Work Breakdown Structure e Rede Lógica

Os projectos não acontecem, precisam de planeamento. Este envolve toda a equipa de projecto no desenvolvimento do plano, este não é um trabalho isolado do gestor do projecto. Esta participação garante que é considerada a experiência é considerada e que todas as pessoas se comprometem a fundo e dessa forma são co-proprietários do plano. Um bom plano oferece o seguinte:

Um mapa da estrada (incluindo milestones compreensíveis) que pode ser seguido por toda a gente da equipa.

  • Uma escala de tempo realista para o projecto.
  • Detalhes dos requisitos dos recursos.
  • Validação do custo estimado.
  • Identificação da derrapagem das actividades.
  • Alerta precoce para os problemas.

Vale a pena usar a experiência anterior e as lições aprendidas em projectos similares.

  • Quanto tempo demorou?
  • Quanto custou?
  • Quais eram as áreas de problemas?
  • Quais eram as áreas com sucesso?

network logicA execução de um projecto sem um plano é tolice. Trabalhar sem saber o destino é susceptível de conduzir a problemas e possíveis falhas. Executar um projecto sem um plano, é como tentar encontrar o caminho numa cidade estranha, sem um mapa. Como diz o ditado, "Se você falha em planear, está a planear falhar."

Work Breakdown Structure (WBS)

Para identificar as actividades individuais de um projecto, é útil criar uma estrutura de divisão de trabalho. A WBS é a base para o plano do projecto detalhado. Ponha a equipa a discutir todas as actividades e subactividades do projecto, sem seguir uma ordem particular. Vamos anotá-las em post-its e colocá-las num quadro branco. Logo que todos pensaram em muitas actividades, passamos a organizar as notas em grupos de acordo com as grandes áreas de actividade. Adicione, altere, remova e embaralhe as notas até que a WBS esteja precisa, completa e lógica. O propósito de uma WBS é decompor o projecto em etapas e sub-etapas.

Rede Lógica (Gráfico de Tempo)

Uma Rede Lógica mostra a sequência de actividades num projecto ao longo do tempo. Ela mostra que uma actividade logicamente precede ou segue uma outra. Criar num post-it um Start (à esquerda) e outro com End (à direita) e colocá-los no quadro branco. Organizar as notas post-it daWBS na sequência lógica das actividades da esquerda para a direita. Junte as notas com setas de entrada e saída, algumas podem ter mais de uma seta. Todas as linhas de conexão em uma rede entrar à esquerda (início) da caixa de actividade (nota pegajosa) e sair à direita (final). As linhas não entram no topo nem saem do fundo da caixa de actividade.

Não são permitidas linhas sem ligação. Todas as actividades devem se ligar a uma outra actividade, ou ao início ou ao fim do projecto. Escrever o tempo que cada actividade irá tomar no post-it para calcular a duração do projecto. Você criou uma rede lógica que o vai ajudar a entender as dependências no projecto, o calendário e o fluxo de trabalho. Esta técnica pode revelar informações importantes que poderiam ser negligenciadas.

Milestones

Procure milestones na sua Rede Lógica. Uma milestone natural pode ocorrer a qualquer momento numa série de actividades paralelas que se reúnem num ponto. Controlar o projecto, definindo resultados concretos para cada etapa. Um resultado concreto é algo que você pode ver ou tocar como uma especificação de projecto, um protótipo, um modelo, um módulo de software.

Utilizar Software de Gestão de Projecto

As informações da WBS e da Rede Lógica podem ser de introduzidas num pacote de software como o Microsoft Project (que toda a gente usa ou julga saber usar) para criar um plano detalhado. Escreva as actividades, predecessores, recursos e estimativas de tempo no software. Uma vez introduzidas, o software irá criar as tabelas e gráficos automaticamente. Não espere pelo software para planear ou gerir o projecto, este é apenas uma ferramenta.

Lista de Verificação

Aqui está uma lista de verificação para o ajudar a criar um plano detalhado do projecto, bem pensado, enquanto se constrói uma equipa de alto desempenho e motivada.

  1. Definir o que deve ser feito usando uma Work Breakdown Structure.
  2. Desenvolva a melhor abordagem para obter tudo o que deve ser realizado através do desenvolvimento de uma Rede Lógica.
  3. Desenvolver estimativas de trabalho e duração e de quanto tempo cada membro da equipe precisa para cada tarefa.
  4. Calcular quanto tempo o projecto levará para completar o seu caminho crítico e milestones com a utilização da Rede Lógica.
  5. Calcular e mapear o número de pessoas necessárias e a percentagem de tempo que cada membro da equipa usa em cada fase do projecto.
  6. Ajustar e refinar o plano de projecto para cargas de trabalho de nível individual e adapte o número de pessoas necessárias durante o projecto.
  7. Optimizar criativamente os trade-offs para entregar os melhores resultados no menor tempo.
  8. Use o processo de planeamento combinado para intensificar o compromisso dos membros da equipe e a propriedade distribuída do projecto.

Texto de Duncan Haughey, PMP, traduzido por Luís Quintino

quinta-feira, junho 09, 2011

Gestão de Tempo num ambiente multi-projecto

Estou preocupado por que continua a haver pessoas que pensam que há aí no mercado o software de gestão de tempo perfeito que irá conseguir resolver os problemas dos seus planos. Na verdade este é um desafio que não pode ser ultrapassado só por tecnologia, pois há aspectos dos hábitos que jogam aqui, para além da natureza própria do desenvolvimento de software.

O manual do PRINCE2 declara que um membro da equipa só consegue realizar 3,5 dias de trabalho produtivo numa semana (no máximo)[i]. Outras actividades tais como reuniões, falar ao telefone, ir a uma festa da empresa, etc. ocupam todo o tempo remanescente.eggs

A lei de Parkinson declara que as pessoas irão usar todo o tempo que têm para realizar uma actividade (por exemplo, para arrumar 1000 revistas são necessárias 2 horas, mas se dermos a uma pessoa 4 horas para isso, irá levar 4 horas). Mas esta noção é muitas vezes interpretada como poder sempre obter mais das pessoas se os espremermos, coloca-los sob pressão, dar-lhes prazos impossíveis de cumprir. Claro que isto pode permitir obter ganhos de curto prazo, mas o mais provável é resultar em desencorajamento das pessoas e diminuição de resultados.

Se pretendemos aumentar a produtividade, certamente existem outras formas possíveis de o alcançar.

Sabemos que um projecto está a trabalhar bem, quando os membros da equipa só colocam questões de dois em dois ou de três em três dias. O que significa que eles sabem o que fazer a seguir e não perdem o ritmo.

Muitas vezes, a deficiente gestão de tempo não decorre de mau agendamento, antes é uma questão que decorre da gestão de projecto. O gestor de projecto é responsável pela decisão das prioridades e não os membros da equipa ou os gestores de recursos. Aqui é que está o problema real, quando a gestão atribui prioridades sem compreender o peso e o efeito em outros projectos. Como a história da manta pequena e dos pés ou dos ombros alternadamente a descoberto. As pessoas preocupam-se demais com as datas de entrega quando deveriam enfrentar o desbaratar de tempo resultante da má optimização das práticas de planeamento.

Devemos ser realistas acerca da disponibilidade dos recursos. Temos de prever a realização de actividade em feriados e os tempos gastos em actividades fora do projecto ou não previstos. A semana de trabalho média é de 4 dias depois de se retirarem estes tempos. Destes quatro dias, pelo menos meio dia será gasto em outros deveres, como reuniões, actividades de gestão e de acompanhamento de outros projectos.


[i] Página 181. Managing Successful Projects with PRINCE2 (3rd Ed.)

segunda-feira, junho 06, 2011

A agenda da reunião do PMO

Muitas empresas realizaram investimentos para implementarem processos e ferramentas de PMO e lutaram e lutam constantemente para alcançarem alguns dos benefícios que este lhes deveria trazer. A criação de práticas regulares de revisão e colaboração são um dos meios para consistentemente chegarmos a resultados. É essencial que os participantes no processo estabeleçam regularidade na aplicação de métodos e práticas de trabalho. A reunião semanal do PMO é uma dessas ferramentas.

Os quatro tópicos principais para a agenda deveriam ser:

  • Revisão de novas boas práticas
  • Revisão de novos projectos
  • Avaliação de Alto Risco
  • Revisão dos Agendamentos em Implementação

 
portfolio_meetingA revisão das novas Boas Práticas

A revisão das novas Boas Práticas consistirá na análise das boas práticas já implementadas nas semanas anteriores. Estas serão baseadas nas Lições aprendidas de projectos que se aproximam da fase final. Pode consistir em qualquer coisa desde um novo processo de aprovação a um workflow de trabalho até a uma forma diferente de trabalho com os clientes. Realizar-se-á uma discussão mínima visto os detalhes já terem sido abordados antes da realização da reunião, e é realizada uma apresentação do tipo «esta é a forma como agora iremos operar».

 
A Revisão de Novos Projectos

Permite que aqueles que pretendam iniciar um novo projecto o apresentem em sumário ao PMO (no máximo com uma descrição de 1 página), incluindo os objectivos de negócio e os benefícios que o novo projecto trarão à organização. Abre-se de seguida um período para questões e respostas. O projecto seguirá para os passos seguintes de aprovação executiva ou colocado para mais pesquisa e aprofundamento com o negócio. O que incluirá a sua referência nas próximas reuniões do PMO.

 
A parte de Avaliação de Alto Risco

Compreende a análise de um relatório das milestones de alto nível dos projectos que mostram com «semáforos» a Vermelho, Amarelo e Verde os status de todos os projectos dentro da organização, filtrados por unidade de negócio. Não se irá perder tempo com o que está a correr conforme o plano, antes, com base numa gestão por excepção, o foco será só nos projectos que estão com dificuldades. Serão tomadas decisões para estes projectos, os obstáculos levantados e os riscos mitigados.

 
A parte final da reunião

O period final da reunião será a Revisão dos Agendamentos em Implementação, para rever as actividades de implementação final que deverão ter cuidados especiais e utilizar períodos específicos do dia. Estas actividades dada o alto pendor crítico recebem o acompanhamento num plano específico e especial atenção será dada a actividades previstas para a próxima semana.

Para que uma reunião de PMO tenha sucesso importa garantir a presença das pessoas certas, que possam (tenham a autoridade para) tomar as decisões no momento. Se durante a reunião alguém pensar «temos de ver isto com..», então não temos as pessoas certas na sala.

Desta forma, com uma hora por semana, conseguimos crescer no nosso nível de profissionalismo, rever e aprovar novos projectos, mitigar o risco e trazer toda a gente para o nível de conhecimento sobre os projectos.

LQ

terça-feira, maio 31, 2011

Delegação de actividades em Projecto

O sucesso na delegação de actividades é essencial para o êxito na gestão de projecto. Contudo, muitas das pessoas envolvidas como líderes em gestão de projecto têm medo da delegação. Eles receiam que, se delegarem, o trabalho não seja correctamente realizado, que os prazos não sejam alcançados. Eles não confiam na colaboração e no trabalho de equipa e habituaram-se a fazer a maioria das coisas e controlarem directamente tudo o resto.
Mas o problema está na forma como fazemos a delegação – esta tem de ser feita de forma efectiva. A gestão de projectos depende simplesmente da delegação por força da lei da divisão do trabalho: uma pessoa ou equipa focada em uma ou duas actividades específicas é mais eficiente e produtiva que uma pessoa que tenta realizar simultaneamente uma multitude de actividades. Uma pessoa não pode ser todas as coisas para um projecto ou um negócio. Se a delegação for feita de forma adequada com facilidade se conclui que quanto mais de fizer o «laissez faire» em gestão de projecto melhor. No fundo que o melhor gestor é o que gere menos.clip_image002
O sucesso da gestão de projecto depende da colaboração e do trabalho de equipa e a delegação bem-feita faz com que estes elementos em surjam com sucesso. Quais os cuidados que devemos ter para delegar quando gerimos um projecto?
Não seja vago – se está a gerir um projecto e se vai delegar actividades, deve ser bastante específico acerca do que se espera realizar com a actividade, quando é que deve ser realizado e o que se espera pela realização da actividade. As descrições vagas conduzem a resultados duvidosos e à falha em cumprir os prazos.
Garanta que estabelece prazos realistas – os prazos devem ser realistas e executáveis dentro do tempo pelas pessoas seleccionadas para a actividade. Obviamente, que a delegação envolve escolher as pessoas certas para as actividades certas de acordo com os seus talentos e competências, mas deve ainda assegurar-se que as pessoas que vão ser atribuídas às actividades não terão conflitos ou problemas de agendamento.
Fornecer toda a informação necessária a cada delegação – forneça aos que receberam a delegação uma direcção para alcançarem os recursos que possam ser necessários para os tornar mais aptos a concluírem o trabalho em tempo. A colaboração e o trabalho de equipa podem estra entre estes recursos.
Garanta que está disponível como líder da gestão do projecto – os seus delegados devem ser capazes de lhe colocar quaisquer questões ou preocupações acerca do projecto ou das suas actividades. Adicionalmente, deve garantir que eles prestam contas o que exige relatórios periódicos. Contudo, não pressione demais. Um relatório semanal de status deve ser suficiente, desde que o projecto leve mais de uma semana a completar.
Está assumido que se delega actividades em gestão de projecto porque não temos tempo para fazer tudo por nós – Pode até ser que estejamos tão afogados que seja difícil dar instruções explícitas para as actividades. Se é este o caso, deve assegurar-se de delegar numa pessoa como o contacto directo e o gestor do projecto. Será responsabilidade desta pessoa ser o seu «braço direito» e quem terá a responsabilidade de fornecer as especificidades para os outros envolvidos para que possa haver êxito na colaboração e trabalho de equipa. Algumas vezes até a coordenação de uma parte de um projecto deve ser delegada. Se tal ocorrer, tenha o cuidado de realizar a delegação para alguém com experiência de gestão de projectos ou no tipo de trabalho que o projecto irá realizar.
Depois de ter delegado, lembre-se de manter as mãos fora do trabalho o mais possível – Permite aos que estão empenhados um espaço criativo no projecto. Deixe-os aparecer com as suas ideias próprias e fazer mesmo sugestões na forma de fazer as coisas melhor. O fundamental é que se obtenha os resultados desejados e o objectivo do projecto. Claro que a palavra final é sua na aprovação das mudanças às coisas, mas, ao mesmo tempo, não há necessidade de ser autoritário.
Para além dos relatórios de status mensais, implemente um processo de relatórios sobre o projecto – É muito importante ter acesso constante a informação sobre a forma como estão a realizar-se as coisas. Faça isto mas monte um sistema com pro-actividade em que as pessoas envolvidas no projecto se sintam confortáveis a actualizar os registos sem necessidade de marcar uma reunião.
Mantenha um registo pessoal sobre quem está a fazer e que actividade – registe todos os relatórios de status e detalhes de progresso. A manutenção destes registos mantém o seu pensamento sobre o projecto e garante uma dupla verificação dos seus detalhes.
Não se esqueça de louvar e mostrar o crédito quando as actividades são concluídas bem e em tempo ou quando se regista um bom progresso na actividade – os membros da equipa precisam de receber um feedback positivo quando estão a fazer as coisas certas. Não só merecem isso como esse reconhecimento ajuda-os a manter o foco, mantém-nos motivados e ajuda-os a compreender o que devem fazer.
Estes são alguns cuidados a ter quando delegamos actividades em gestão de projecto. A delegação não é uma coisa simples. Exige consideração, compreensão dos requisitos de projecto e um entendimento das capacidades e competências dos que colaboram connosco
O trabalho de equipa e a colaboração conseguem-se se for feita uma delegação correcta desde o início. Através da delegação conseguimos guiar um projecto até aos seus resultados desejados, sem dores de cabeça, sem excesso de micro-gestão e com todos os envolvidos muito mais contentes e o projecto alcança o que todos desejam – o sucesso.












quinta-feira, maio 19, 2011

Como impressionar com uma Apresentação

Os gestores de projecto têm de ser capazes de apresentar o seu trabalho, tal como as conclusões da análise das questões presentes, as alterações propostas e o status das realizações e projectos em curso. Se pesquisar no Google por apresentação executiva, por exemplo, vai obter um monte de links mas muitas vezes os recursos obtidos estão focados em como preparar ou como se comportar durante a apresentação. Há outro aspecto importante que é: o que é que deve estar contido na apresentação e como deve ser organizado o conteúdo?

Iniciar o projecto

Tente limitar o sumário ou visão geral a UM slide

imageOs executivos de empresas têm muito pouco tempo para entrar em detalhes dos projectos, assim a abordagem correcta é sumarizar o projecto exactamente num único slide. Este slide deve fornecer uma visão geral dos pontos-chave de relance. Como este pode ser o único slide para o qual terá tempo para apresentar deve ser sucinto e directo. Ao concentrar-se neste slide singular deve focar-se em apresentar só a informação essencial. Frases curtas. Em vez de pontos são muito melhores, especialmente se a apresentação seja distribuída posteriormente e entregue aqueles que não puderam estar presentes. Poderá sempre entrar em detalhes durante o resto da apresentação, mas este slide deve valer por si.

Utilize metáforas

A mente humana adora metáforas, especialmente as mais curiosas. Eu uso uma de uma estrada com distância entre cidades para preparar as pessoas para uma abordagem faseada que se move do estado presente com os seus pontos quentes para uma meta. Deve usar aquilo que for apropriado para a visualização dos participantes e do projecto.

Dê uma direcção


Para obter a atenção das pessoas pode usar a transição de estados das diversas fases com a base da apresentação dos slides. Importa definir as questões mais importantes, alinhar a transição de fase com os objectivos de negócio da empresa e desenhar o estado futuro almejado pela meta definida. As pessoas serão assim capazes de se situarem.

Anuncie pontos de paragem

conforme a natureza da mensagem, pode dividir a estrada em diversos segmentos com pontos de paragem que definem as fases. Estes pontos de paragem são portões que serão utilizados para avaliar os resultados da fase concluída antes de tomar decisões para avançar para a fase seguinte e quanto tempo irá ser necessário para a realizar, a que custo e quais os riscos conhecidos, que alterações se prevêem, e depois salientar as realizações esperadas para manter todos motivados.

Enfrente os riscos

Contudo a imagem que damos não pode ser completamente idílica. Não há acções sem riscos e então é melhor identificar os riscos desde o início. Os participantes vão adicionar mais uns quantos através das suas dúvidas, discussões e questões e deve assegurar-se que os anota. Faça o possível por anotar a importância da identificação e mitigação dos riscos como um importante processo que continua durante todo o projecto.

Mostre os custos em relação com as poupanças

Não há refeições grátis. Utilize essa ideia para manter os participantes com o pensamento naquilo que importa. Quando se apresentam estimativas de custo é importante mencionar poupanças e/ou benefícios mesmo quando são só potenciais. A chave está em que se ponderou sobre este aspecto de negócio do projecto. Lembre-se que a qualquer estimativa inicial de custo, mesmo quando se sublinha «estimativa», será registada e infelizmente nunca será esquecida.

Conclua com um sumário

No fim da apresentação, sumarize rapidamente as etapas e as realizações chave, os custos projectados, as poupanças esperadas, as mudanças ao estado presente e como irá apresentar-se a meta estabelecida no futuro.

LQ

terça-feira, maio 10, 2011

Plano do Projecto – como escrever um plano vencedor

O Plano do Projecto é um dos documentos mais importantes e úteis na sua caixa de ferramentas e deve ser permanentemente acompanhado e actualizado durante a vida do projecto. O seu propósito inicial é o lançar o projecto convencendo os decisores (aqueles que controlam o financiamento, por exemplo, o Board do Projecto ou o comité de pilotagem) que o projecto é viável e que irá atingir as necessidades previstas dentro da escala de tempo definida, cumprindo o orçamento e atingindo as expectativas.

Se o plano do projecto está escrito de forma incompleta ou deficiente, o projecto pode nem sequer passar a primeira decisão e pode nem arrancar. Muitos projectos viáveis ficaram neste estágio devido a deficiente planeamento e pobre comunicação. No lado positivo, pode realizar um grande plano do projecto, que estabelece a sua credibilidade como gestor de projecto, inicia com solidez o projecto e fornece à equipa de projecto como um mandato para a acção e uma direcção clara a seguir.songdo_city

Não deve confundir um plano de projecto com um agendamento de projecto (schedule). Um agendamento é somente um elemento do plano do projecto e toma a forma de uma linha de tempo ou gráfico de Gantt ligando as actividades à linha de tempo. O agendamento do projecto é uma ferramenta vital e deve complementar o plano de projecto Os grandes planos de projecto contém diversos agendamentos normalmente como apêndices, que são referidos ao longo do documento. Estes agendamentos devem incluir a escala de tempo total, um agendamento para teste, um agendamento de implementação, a análise do caminho crítico, um agendamento de atribuição de recursos, etc.

O que deverá ser incluído no Plano do Projecto?

O Plano do Projecto serve como um mapa das estradas para a equipa de projecto e oferece orientação na prioridade das actividades, o âmbito do trabalho, as metodologias e a governação que será usada, quem são os stakeholders, qual a abordagem global a adoptar, como serão geridos os custos e as pessoas, quais os standards de qualidade do projecto, como é que o projecto irá comunicar com os stakeholders, como será medida a performance e os benefícios, etc.

As principais áreas que devem ser cobertas no plano incluem:

  • Background do projecto
  • Objectivos
  • Âmbito
  • Constrangimentos
  • Assumpções
  • Dependências e impactos
  • Questões e riscos
  • Metodologia e estratégia
  • Controlos; âmbito, tempo, custo, qualidade, recursos
  • Comunicações
  • Agendamento da realização
  • Medida de performance
  • Realização dos benefícios

Como vê existem muitos elementos num plano de projecto e alguns dos maiores planos podem atingir mais de 100 páginas em extensão. Esta característica faz com que a seja muito importante a estruturação do documento. Um formato consistente com uma ordem lógica e títulos claros irá permitir aos leitores navegar rapidamente através do documento e obter os detalhes que são importantes.

Tente nunca omitir nenhuma das áreas críticas que referimos acima, porque isso pode comprometer a decisão ou exigir mais custos no futuro se ocorrer uma incompreensão. Por exemplo, se não se conseguir identificar correctamente o que está fora do âmbito do projecto, podemos vir a ter uma disputa durante a sua execução. Ou pode acontecer que sente que o projecto está a realizar um produto que julga satisfatório, mas que falha na consecução das expectativas do cliente porque têm critérios diferentes de qualidade. Estas não são situações em que se queira ver envolvido e podem ser facilmente evitadas se escrever um plano detalhado e completo.

Quanto mais informação relevante e detalhada incluir no plano nesta fase inicial melhor, mas deve sublinhar relevante. Evite a tentação de incluir no seu documento parágrafos desnecessários e tente não se repetir. Se necessitar sublinhar um ponto, refira essa secção num índice (usando títulos) em vez de repetir toda uma secção. Utilize as referências para dar ênfase a questões que devem estar presentes para o leitor. Este agradecerá esta atenção e, ao mesmo tempo, fará com que seja mais fácil editar o documento. Claro que atingir o nível adequado de detalhe é difícil e só pela experiência irá ficar mais habituado a isso. Depois de ter escrito alguns planos de projecto saberá como adaptar cada um de acordo com a dimensão do projecto e as expectativas da sua audiência. Como fazer isso?

Adaptar à audiência

O plano do projecto é muitas vezes dos primeiros pontos de referência para os stakeholders, sejam novos membros da equipa, executivos, clientes, utilizadores, fornecedores e outras partes interessadas. Assim, quando escreve o plano deve ter na mente que este deve estar adaptado para tal ampla audiência e deve poder ser lido por alguém que não tenha um conhecimento prévio do projecto. Garanta sempre que introduz o contexto do projecto e oferece alguma informação anterior e história sobre aquilo de que se fala. Inclua um glossário ou termos de referência para explicar as abreviaturas e acrónimos. Quando se referir a outros documentos pode ser útil incluir detalhes nos apêndices para benefício das pessoas que não tenham lido antes esses documentos.