O uso de Project Controls conduz a melhor performance do projeto

Os controlos do projeto são um grupo de processos que recolhem e analisam os dados do projeto para manter os custos e os cronogramas no caminho certo. A beleza dos controlos do projeto é que eles permitem a monitorização proativa dos projetos atuais e alertam as partes interessadas para que ações corretivas e oportunas que possam ser tomadas.

A existência destes processos vive das pessoas que os desempenham em representação muitas vezes do cliente impulsionandos os empreiteiros em melhorar a informação prestada no projeto.

Embora os controlos entreguem projetos dentro do prazo e do orçamento, o âmbito dos seus benefícios estende-se muito além disso, levando a melhorias significativas no desempenho do projeto e da companhia.

Com ênfase na monitorização rigorosa, recolha frequente e regular de dados, relatórios de status, comunicação e adaptabilidade às alterações, os controles do projeto geram uma tonelada de métricas de desempenho que ajudam a manter a orientação certa sobre o status atual e orientar o projeto na direção certa. Como resultado, os projetos que possuem controles de projeto fortemente integrados demonstram resultados estelares.

Impacto dos controlos nas funções críticas do projeto

O desempenho do projeto é definido como um projeto dentro do tempo, do orçamento e que entrega os resultados pretendidos. Um projeto é classificado como de alto desempenho quando atende ao prazo, orçamento e outros critérios que foram definidos para ele. Se pelo menos um desses objetivos não for atingido, um projeto poderá muito bem ser considerado um fracasso.

Infelizmente, os projetos concluídos dentro do orçamento são a exceção e não a norma. Uma análise da PwC estima que os megaprojetos, definidos como aqueles que excedem as receitas de US $ 1 bilhão, geralmente excedem seus orçamentos em 50% ou mais.

Para que as empresas evitem essas armadilhas e melhorem o desempenho do projeto, muitas funções - incluindo gestão de portfólio de projetos e gestão de contratos - devem unir-se em conjunto com os controles do projeto.

Vamos ver como os controles do projeto melhoram o desempenho de funções específicas do projeto.

Previsão

A previsão é uma ferramenta essencial dos controlos do projeto que usa dados históricos e atuais do projeto para prever custos e resultados futuros. Usa métodos de previsão aplicados à boa avaliação do progresso, os project controllers podem estimar com precisão se os custos e cronogramas permanecem ou não no caminho ou a que distância estarão.

Uma melhor previsão leva a um melhor desempenho e controlo de custos. Por exemplo, a previsão permite o mapeamento dos resultados esperados logo nos estágios iniciais e o ajuste ao longo do ciclo de vida do projeto. Esses insights fornecem aos gestores de projeto os insights necessários para estarem sempre conscientes dos desvios de orçamento e de milestones e oferecem oportunidades para tomar ações corretivas, como reduzir o âmbito ou ajustar recursos.

Agendamento (Scheduling)

O planeamento é o processo de definição de cronogramas e mapeamento de recursos em relação a cada tarefa identificada na estrutura de detalhe do trabalho do projeto (WBS). Um cronograma do projeto é um plano que permite acompanhar o progresso no tempo e alinhar as expectativas de todas as pessoas envolvidas em um projeto.

Os controlos do projeto melhoram a função de agendamento, impondo um cronograma realista do projeto, que leva em consideração os riscos. Métricas de acompanhamento, como percentagens de variação, fornecem visibilidade sobre o status do cronograma, permitindo a identificação e a gestão antecipada de obstáculos que podem prejudicar a linha do tempo do projeto. A estrutura de comunicação transparente dos controlos incentiva os membros da equipe a destacar problemas e a corrigir o curso quando necessário.

Controlar os custos do projeto

Controlar os custos do projeto é a função que visa minimizar a diferença entre os custos planeados e os reais.

Os controlos do projeto fazem uma enorme diferença na gestão de custos, pois fornecem uma abordagem orientada a dados para monitorizar continuamente se os custos estão dentro do orçamento. Como os pontos de verificação são frequentes e em tempo real, os controles ajudam a prever com precisão as escaladas de custos. E, como se prevê as superações no início do jogo, os controlos oferecem tempo suficiente para corrigir o problema.

Por exemplo, um projeto é medido como excedendo o orçamento e previsto para continuar nessa tendência ascendente. Os controlos oferecem a oportunidade de melhorar a utilização de recursos - e outros aspetos do projeto - para que o resultado esperado possa ser corrigido.

Gestão de Mudanças

A gestão de mudanças é um conjunto de abordagens focadas no controlo de mudanças, além de permitir que as equipas de projeto se adaptem a mudanças imprevistas durante o ciclo de vida do projeto.

Embora as mudanças sejam inevitáveis ​​num projeto, a maneira pela qual elas são geridas pode determinar o curso do projeto. Os controlos do projeto adotam uma abordagem proativa, garantindo que as partes interessadas definem e aprovam adequadamente todas as alterações antes da execução. Por exemplo, antes do estágio de aprovação, as equipas precisam confirmar a disponibilidade de recursos.

Os controlos do projeto também estabelecem uma cultura na gestão de mudanças, onde todas as mudanças são discutidas o suficiente para evitar mudanças desnecessárias. Além disso, os controlos do projeto garantem que as equipes assumam a responsabilidade pela mudança proposta, bem como pelo consequente impacto no custo e no cronograma.

Gestão de riscos

A gestão de riscos é o processo de identificação, planeamento e minimização ou mitigação de incertezas e qualquer impacto negativo que estas possam ter nos objetivos do projeto.

oO foco dos controles do projeto na transparência dos dados - para executivos seniores, clientes e membros da equipe - cria um ambiente em que todos estão mais bem preparados para enfrentar os riscos. Este sentido de comunicação e visibilidade do que acontece e do que pode acontecer potencialmente força a preparação, mantém todos alertas para identificar os riscos antecipadamente e evita que os riscos escapem pelas fendas.

Além disso, o ciclo contínuo de medir e melhorar projetos via monitorização, análise e mitigação interrompe ameaças iminentes e aumenta a qualidade do projeto.

Processos e sistemas padronizados

Projetos que possuem processos e sistemas em funcionamento respondem bem às mudanças. Os projetos mais ágeis e previsíveis possuem sistemas para os membros da equipa, canais de comunicação definidos e ferramentas apropriadas para gerir e executar o trabalho. Por exemplo, as organizações que passam por relatórios mais frequentes e usam informações de desempenho para gerir projetos têm uma taxa de sucesso de 68% em comparação com uma taxa de sucesso de 7% para aquelas que não o fizeram.

O pilar de controlo do projeto aumenta a qualidade do projeto, impondo o estabelecimento de tais processos para recolha, gestão e análise de dados. Estes, por sua vez, influenciam o tempo, o custo e os resultados do projeto para melhor. Permitem também que os executivos comparem projetos diferentes, isolem problemas específicos de projetos versus problemas sistêmicos e, portanto, melhorem o desempenho em toda a organização.

Gestão de Performance

A gestão de desempenho é um conjunto sistémico de atividades que ajudam a alcançar as metas do projeto por meio de monitorização e ação contínuos.

Os controlos do projeto levam ao alto desempenho. Utilizam indicadores-chave de desempenho confiáveis ​​(KPIs), em vez de estimativas ambíguas, para tomar medidas corretivas. Os KPIs oferecem aos membros da equipa uma visão clara das tendências de desempenho e correções do projeto. Em outras palavras, os controlos do projeto suportam uma melhor gestão de desempenho, obtendo em resultados superiores.

Os bons processos de controlo de projetos oferecem ferramentas de monitorização em tempo real, acompanhadas de uma estratégia meticulosa para as partes interessadas agirem em determinados pontos de dados. Eles também precisam ser integrados ao cenário holístico do projeto, unindo vários elementos da gestão de projetos, para que não gerem simplesmente dados díspares, mas gerem insights úteis e acionáveis ​​no momento certo.

Tomar melhores decisões

Chegado de Tripoli, aonde estive a aconselhar e a apoiar um cliente em vários grandes projectos, eis um assunto que me saltou para a frente, ao observar gestores a tomarem decisões incompletas e titubeantes, ao mesmo tempo, que os problemas se agudizavam.
Os bons leaders tomam grandes decisões. Será que têm um processo para fazer isso? Quais são então as técnicas para a tomada de decisões rápida?

Muitos leaders usam um processo de 5 passos para tomar as suas decisões. Este é um processo comum que pode ser utilizado para melhorar o processo de tomada de decisões. Quais são os passos:

Investigar o problema

Quando um problema se coloca toma em primeiro lugar, todo o tempo que necessitar para identificar a sua causa primária e certificar-se que não é só um sintoma de outro problema escondido. Os problemas em projecto relacionam-se usualmente com pessoas, processos, equipamento ou materiais. Descubra quando, porquê e como ocorreu e qual o seu impacto no seu projecto.

Estabeleça prioridades

Nos projectos os problemas estão sempre a ocorrer. Deve determinar-se quando um problema necessita de atenção urgente ou não, com base no seu impacto para o projecto. Se tem alto impacto (p. ex. impedindo a equipa de poder trabalhar) então é de «alta prioridade» e é preciso acabar o trabalho e resolver rapidamente o problema.

Identificar as soluções

Quando temos uma compreensão clara do problema e do seu nível de prioridade, precisamos identificar ar as soluções para o enfrentas. Depois devemos rever cada alternativa para determinar se:

• Resolve a causa primária do problema
• É fácil e prática de implementar
• Previne o problema de voltar a ocorrer

Tomar a decisão

Agora dispomos já de toda a informação necessária para tomar a decisão. Não tome, no entanto, as decisões demasiado à pressa. Tomem algum tempo do dia para ponderar cuidadosamente todos os prós e contras. Vá passear, ou se é mesmo muito importante durma em cima da decisão para poder ter a cabeça fria e clara quando decidir. Tome as decisões menos importantes com rapidez, mas tome mais tempo quando toma decisões que são críticas para o sucesso do projecto

Agir sobre a decisão

Quando pensou sobre tudo e tomou a sua decisão, precisa de estar completamente comprometido para as implementar. Aja de acordo com a decisão e comunique à sua equipa ao mesmo tempo que define e planeia as actividades necessárias para a realizar e fazer acontecer. Lembre-se que qualquer problema afecta o seu projecto de alguma forma, o que exige que se actue de forma rápida logo que se decide o que fazer. 
Desta forma toma melhores decisões de forma mais rápida e sentimos que estamos a gerir melhor.
Uma forma de melhorar o processo de decisão é a utilização de metodologias de gestão consistentes em projecto que ajudarão a guiar o projecto e a equipa ao longo de todo o processo.

Resolver Conflitos

Todos os gestores de projecto enfrentam conflitos. Mutas pessoas, também nas suas carreiras, em algumas fases, têm conflitos. No entanto, dada a pressão colocada sobre as equipas de projecto, não é estranho que os conflitos ocorram aqui com maior frequência.
Como, então, enfrentar e resolver os conflitos?

Precisa enfrentar o conflito e não ignorá-lo, já que ignorando-o só vai tornar o problema pior. Alguns exemplos de problemas:

• O seu chefe está frustrado com o progresso e descarrega em cima de si, em frente dos outros membros da equipa.
  
• Um seu colega quer alguma coisa de si que você não lhe pode dar, ou não pode produzir no tempo dado e este fica zangado.
  
• A equipa pensa que você não é realista acerca da escala de tempo e assim respondem mal, levantam a voz e tornam-se obstrutivos.

Quando ocorre o conflito pode tomar as seguintes acções:

• Faça um intervalo: Se a outra pessoa fica muito destemperada, diga-lhe que precisa de cinco minutos para pensar. Vá tomar um café e dê uma volta. Isto irá ajudar a que ambos se aclamem e reflictam sobre o que aconteceu.
  
• Pacifique: quando recomeçar a conversa inicie-a com: «Eu sei que está sobre grande pressão por causa de…». Isto irá pacificar a relação um pouco e poderá tornar mais positiva a atmosfera.
  
• Solução de Problemas: Concorde com ele que existe o problema e que ambos precisam de trabalhar para, de forma construtiva, o resolver. Discuta as várias soluções e tente acordar nos prós e contras de cada uma antes de tomar uma decisão sobre o melhor caminho.
  
• Linguagem corporal: Enquanto decorre isto, precisa focar-se na linguagem corporal. Mostre abertura. Tire as mãos dos bolsos e nunca cruze os braços. Tente utilizar movimentos lentos de mãos. Utilize um tom de voz passivo e não mostre emoção. Mantenha um bom contacto com os olhos. Ouça com cuidado e verifique a linguagem corporal do seu interlocutor.
  
• Um mediador: Se os passos acima estão a obter poucos resultados, então é necessário falar com mais alguém que possa informalmente mediar o conflito. Diga que quer chamar um colega para a conversa já que ele terá mais ideias para a solução. Convide alguém que tenha um perfil de solucionador de problemas e em quem ambos confiam.
  
• Dar feedback: Quando a conversa ficar um pouco mais relaxada é tempo de dar à pessoa alguma informação construtiva. Diga-lhes como gostaria que enfrentassem a próxima questão similar. A oferta de um feedback positivo e construtivo pode ajudar a alterar comportamentos.

Uma boa forma de evitar conflitos é utilizar modelos comuns para a gestão e comunicação no projecto, bem como processos uniformes e consistentes – ferramentas comuns para enfrentar os desafios do Projecto.

Porque não deve ir para a Gestão de Projecto?

 

Muitas pessoas têm alguns traços para serem um bom gestor de projecto, mas também têm muitos que o fazem considerar ser mau para essa posição. 
Coleccionei uma lista de indicações que mostram que podem não estar bem preparados para ser um gestor de projecto. Repare que estas notas não têm nenhuma hierarquização.

#1: Você é um comunicador pobre

Diz-se que mais de 50% do tempo de um gestor de projecto é dispendido em algum aspecto de comunicação. Isto inclui reuniões, relatórios de status, emails, chamadas telefónicas, coordenação, falar com pessoas e completar documentação. 
Alguns estudos mostraram que a comunicação verbal e escrita ocupa 80% da função. Se você não é um comunicador efectivo (e você não procura sê-lo) então não siga por este caminho.

#2: Você não consegue trabalhar bem com outras  pessoas

Prefere ficar no escritório e focar-se no seu próprio trabalho, provavelmente não possui uma capacidade colaborativa para ser um bom gestor de projecto. Bons gestores de projecto devem gastar muito tempo com clientes, stakeholders, e membros da equipa.

#3: Você prefere os detalhes

Muitas pessoas gostam de trabalhar nos detalhes do projecto. Necessitamos sempre de dispor de pessoas destas. Mas quando se é gestor de projecto, devemo-nos erguer acima dos detalhes e tornarmo-nos mais como quem delega e como quem coordena. Precisamos de confiar em outros, quando se desempenha a função de gestor de projecto, para que façam uma grande parte do trabalho detalhado .

#4: Não gosta de gerir pessoas

Não há muito de um projecto se você for o único recurso. Se quer ser um bom gestor de projecto deve ser capaz de gerir pessoas. Não terá 100% da responsabilidade sobre as pessoas, mas terá de mostrar liderança, torná-los responsáveis e aptos a prestarem contas, gerir conflitos, etc. 
Alguns gestores de projecto dizem que poderiam realizar um trabalho muito melhor se não tivessem de se relacionar com pessoas. Se é isso que sente então a gestão de projecto provavelmente não é para si.

Limiar de estimação

Quando se cria um plano de trabalhos não se sabe geralmente o suficiente para descrever com detalhe,pelo menos na primeira vez, as actividades . Ao invés, identificam-se grandes actividades em primeiro lugar e decompõem-se estes grandes bocados em actividades mais pequenas. Estas mais pequenas são por sua vez desdobradas em actividades mais pequenas e mais concretas. Esta técnica é denominada de criação da Work Breakdown Structure (WBS).

Uma pergunta adequada seria saber qual a dimensão que devem assumir as actividades pequenas até não ser necessário decompô-las. Isto é referido como o «threshold» ou limiar de estimação. O trabalho pode ser decomposto para além do limite de estimação, mas normalmente nenhum trabalho é deixado a um nível mais elevado. O limite pode ser diferente conforme a dimensão do projecto e conforme a sua compreensão pelos destinatários.

Pode, entretanto, utilizar-se como guia o seguinte critério. Para um projecto de grande dimensão (por exemplo 5000 horas de esforço ou mais) qualquer trabalho que seja maior do que 80 horas deverá ser decomposto em actividades mais pequenas. Projectos de média dimensão (ou seja, de 1000 de esforço ou mais) não deverão ter actividades superiores a 40 horas. Se o projecto é pequeno (200 horas), as actividades deverão ser decompostas até não mais de 20 horas. Estas indicações são os limites superiores podendo as actividades serem decompostas mais abaixo.

A alocação de trabalho menor do que o limite definido permite que este trabalho seja melhor gerível. Por exemplo, se o seu projecto tem 250 horas e tem actividades que possuem cada uma 80 horas, não tem possibilidade de recuperar de uma destas actividades se a mesma se atrasar. Contudo, se a actividade mais longa tiver 20 horas, terá possibilidade de determinar se o trabalho está a ser realizado em tempo.

Evidentemente que é possível que actividades que devem ser trabalhadas num futuro distante possam estar decompostas acima do limite definido, pois há tanto que ainda é desconhecido acerca do trabalho em si. Neste caso a abordagem deverá se de decompor o trabalho em dois projectos distintos. O segundo projecto poderá ser definido com mais exactidão com base nos resultados obtidos com o primeiro projecto.

No caso de não ter a possibilidade de utilizar projectos múltiplos, o trabalho futuro pode ser deixado a um nível mais elevado que o do limite de decomposição. Contudo, se deixa trabalho futuro a alto nível, continua a ser critica a sua decomposição em partes menores pelo menos 2 a 3 meses antes da necessidade de execução do trabalho. 

Além de permitir que faça uma gestão mais eficaz do trabalho, outro motivo para dividir as atividades em partes menores é garantir que se entenda o que o trabalho significa. Quando atribui um membro da equipe a uma atividade do plano de trabalho, ele pode não entender o que é o trabalho e pode pedir uma explicação. Se não sabe o que o trabalho quer dizer, terá problemas. Então, deve garantir que o trabalho seja dividido num nível pequeno o suficiente para que as atividades sejam compreensíveis. Por exemplo, se uma atividade que é estimada em 80 horas nunca foi feita antes, ainda pode precisar ser dividida em atividades menores para garantir que o membro da equipe que é atribuído ao trabalho sabe exatamente o que é esperado.

Esses dois fatores - a capacidade de gerir de forma eficaz o trabalho e compreender o trabalho necessário - devem orientar a decisão sobre o quão pequeno fazer as atividades.

Progress Reporting

Se trabalha como gestor de projeto, é muito provável que você tenha dezenas de relatórios de progresso realizados durante a sua carreira - se não centenas! Mas foram mesmo eficazes? Teve um propósito claro ao escrever os relatórios, por exemplo, querer que os stakeholders tomassem determinada ação como resultado dos relatórios? Ou só os produziu porque era uma dessas atividades de rotina que tinha de ser feita?

Pode ter sido muito consciente e determinada ao produzir os relatórios, mas, infelizmente, nem todo mundo é igual, e como resultado, o relatório de status semanal torna-se um desses artefactos que faz parte do processo sem adicionar muito valor.

Erros Principais

Alguns dos erros clássicos que os gestores de projeto fazem é incluir demasiadas informações estáticas e não introduzir o suficiente sobre o que são os problemas do projeto real. Desta forma, o relatório não é um verdadeiro reflexo do que realmente acontece. Se acabou de escrever sobre o que aconteceu durante o último período de referência e o que você vai fazer durante o próximo período de referência, sem mencionar como isso se compara a planear e quais são os riscos reais e questões do projeto, então não há incentivo para que o cliente preste atenção a ele. Em muitos casos, o relatório é mesmo anexado num e-mail sem qualquer contexto ou descrição, o que significa que é improvável que alguma vez chegue a informação aos executivos que dependem de smartphones ou doutros dispositivos móveis.

O relatório de progresso perfeito

Então, o que é um relatório de status perfeito? Bem, em primeiro lugar, é um relatório simples, de preferência numa página de informação que adiciona valor real, fornecendo uma visão geral das milestones, riscos, questões e informação de custos, no mínimo.

Algumas orientações sobre o que se deve e não deve fazer:

• Não inclua demasiada informação estática acerca do background do projeto, a não ser que seja parte do processo.
• Inclua sempre o nome do sponsor e do gestor de projeto.
• Mantenha a informação viva numa página só.
• Inclua os 5 riscos e questões principais, incluindo o responsável e ação de mitigação.
• Inclua informação sobre o orçamento e como se está a acompanhar.
• Inclua uma visão geral das principais milestones, as suas datas planeadas e o estado de cada uma delas.
• Faça uma lista das realizações chave do período anterior.
• Faça referência a métricas importantes alcançadas, mas faça-o de forma simples e gráfica.
• Seja claro quanto às ações que quer que sejam feitas; este relatório é só para informação ou requer-se uma decisão de alguém?
• Não envie o relatório por email sem fornecer o contexto no corpo do email. Os destinatários podem nunca ler o relatório, então forneça um sumário no email.
• Não envie más notícias num relatório de projeto sem antes falar com as pessoas. Não queremos que o cliente leia acerca de 

Chegar a acordo com a Data de Conclusão

Por definição todos os projetos tem de ter uma data de fim. A forma como o planeador e o gestor do projeto chegam a essa data e como a equipa de projeto enfrenta a data de fim varia muito de projeto para projeto. Nada tem mais efeito na equipa do projeto que a data de conclusão do mesmo, e não há nada que crie mais stress nas pessoas que estão envolvidas efetivamente no trabalho do que a forma como é compreendida a data de conclusão por todos. Chegar a acordo com a data de fim, significa conseguir ganhar para a data de conclusão todos os envolvidos no projeto. Todos tem de acreditar que o projeto pode ser feito até essa data.

Em termos gerais, temos três diferentes maneiras de encontrar a data de fim de um projeto e se as entendermos isso ajudará a equipa a chegar a acordo com isto.
 

A data indicada

Quando a data de conclusão é indicada pelo cliente ou pela gestão, o gestor do projeto tem de aceitar isso e planear o agendamento do projeto à volta desta data de fim. Embora isto não seja a forma ideal de planear um projeto é a mais comum no mundo de hoje. Se o gestor de projeto tenta puxar a data para mais tarde, o cliente pode decidir encontrar uma nova equipa para realizar o trabalho.

Esta é a data mais difícil para chegar a acordo internamente porque muitas vezes não faz qualquer sentido para a equipa. O gestor de projeto vai ter de equilibrar entre a realidade do agendamento para encontrar a data; terá compreender que âmbito pode ser realizado para cumprir a data indicada. Terá de ser compreendida também a necessidade que está por detrás da indicação da data de fim, pois apesar das aparências muitas vezes esta data não é arbitrária e, se a compreendermos, será mais fácil aceitá-la. Aceitar a data significa ainda enfrentar os riscos envolvidos na realização deste deadline forçado e gerir cuidadosamente o âmbito do projeto dentro dos constrangimentos de datas.
 

A data agendada do projeto

O exato oposto da data indicada é a data agendada do projeto. Esta decorre da inclusão de todo o trabalho no software de agendamento, são anotados os constrangimentos e os recursos atribuídos e o software analisa e calcula a data em que o projeto irá terminar. Esta é possivelmente a forma mais fácil de chegar a acordo com esta se tivemos em conta, de forma verdadeira, todas as variáveis.

Por exemplo, se o agendamento foi calculado com calendários de 60 horas ou semanas de 80 horas de trabalho e se as atividades foram agendadas sem flexibilidade. Então esta data agendada será tão arbitrária como uma qualquer data definida por alguém sem nenhum conhecimento do projeto. Para que a data seja adequada necessita do envolvimento do gestor do projeto e do planeador na criação de um plano com datas realistas dentro dos constrangimentos de recursos e âmbito.
 

A data negociada

A terceira forma de obter a data de conclusão é negociar a data com o cliente. Muitas vezes, esta negociação vai cair entre a data indicada e a data agendada e, embora possa não ser a ideal o gestor de projeto pode ter capacidade de a tornar aceitável desde que os riscos estejam sob controlo e sejam revistos durante a negociação. Espera-se que todos fiquem de acordo com a data depois da negociação e que isso envolva uma compreensão do que foi alcançado e quais os compromissos resultantes da negociação.

Este é o processo do bom senso e é aquele que resulta do esforço de obter a data mais adequada para todas as partes. No decurso do projeto é esta a data que decorre dos processos de atualização e revisão bem como das extensões de tempo necessárias a enfrentar as mudanças nos constrangimentos e nas necessidades afirmadas pelo cliente.

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!».

Gerir trabalhadores remotos

Por Ten Six traduzido e adaptado

No trabalho global dos nossos dias gerir trabalhadores remotos e equipas é muitas vezes um grupo de indivíduos que não trabalham no mesmo escritório, que não falam a mesma língua que quando estão em casa e que, muitas vezes, nem sequer trabalham para o mesmo empregador. São equipas virtuais extremas. Nesta situação e abrangendo aquilo que muitos gestores de projecto hoje enfrentam no que respeita aos trabalhadores remotos, os membros da equipa podem estar espalhados pelo país todo ou baseados no escritório da sede.

Há alguns cuidados que os gestores devem ter como:

Garantir que todos têm acesso às mesmas ferramentas

As equipas de projeto necessitam de ferramentas: planos, relatórios semanais, software de acompanhamento das atividades e etc. as ferramentas de gestão empresarial de gestão de projeto tendem a ser alojadas centralmente, se é bom quando estamos à secretária na sede ou no escritório, mas que não são tão úteis se trabalhamos a partir de casa. Garanta que todos os membros da equipa que estão baseados fora do escritório têm acesso às mesmas ferramentas. Fale com a direção de TI na forma de melhor estabelecer os seus acessos remotos.

Inclua os trabalhadores remotos nos eventos sociais

A confiança nas equipas de projeto é construída em volta da partilha de pequenas experiências e confidências com outros membros da equipa e assim a tentativa de envolver todos os membros da equipa em eventos sociais deve ser estimulada. Celebre os aniversários de todos. Encontre formas criativas para a participação de toda a equipa nestes eventos.

Estabeleça objectivos claros

Assegure-se que as pessoas que trabalham remotamente têm expectativas claras acerca daquilo que é suposto fazerem. Necessitam de objectivos claros para o projeto e para o seu comportamento. Devem contribuir com informação de projeto todas as semanas? Participam numa chamada mensal da equipa? Quais os são os standards a usar no trabalho em mão? Trabalhe em conjunto com os membros da equipa para estabelecer metas claras, objectivos escritos e tornar os membros da equipa responsáveis por contribuir com um feedback regular.

Forme toda a equipa

Formar uma pessoa em como se deve trabalhar de forma remota parece estranho. Na realidade deve ser o mesmo do que trabalhar no escritório, só localizado mais longe? De facto, o trabalho remoto é diferente. Há distrações diferentes e se estamos baseados em casa pode ser-se afectado por um sentimento de isolamento. Os trabalhadores remotos podem necessitar de formação em tecnologia como aceder a sistemas remotos ou como usar web conferências com efetividade. Competências soft como comunicação tornam-se muito importantes e assim os trabalhadores remotos podem beneficiar de formação nestas áreas.

Os gestores de projeto podem também necessitar de serem treinados em como gerir membros de equipa remotos. Por exemplo, não se pode observar a performance de uma pessoa se ela não está connosco, assim é preciso aprender a gerir (e avaliar) por resultados. De novo, as competências de comunicação são chave e o gestor de projeto deve aperfeiçoá-las.

Finalmente, a equipa restante – aqueles que estão baseados em conjunto – podem também beneficiar de alguma formação ou pelo menos de uma sessão de revisão. Esta pode cobrir coisas como a forma de contactar os trabalhadores remotos, a razão de alguns estarem a trabalhar remotamente e outros não, como trabalhar em conjunto para garantir o sucesso do projecto e o seu avanço e quaisquer questões relacionadas com a partilha de ficheiros.

Mantenha-se organizado

A mais importante orientação para a gestão de trabalhadores remotos é manter-se organizado. Lembre-se que eles estão lá e que eles são uma parte valiosa no sucesso do projeto. Os membros remotos da equipa com objectivos planeados e agendados. Devem ser convidados para as reuniões da equipa o que implica que devemos ser ainda mais organizados e marcar as salas de reunião com capacidades de web conferencing em vez de instalações para reuniões em pé ou junto das mesas de trabalho.

A utilização de trabalhadores remotos adiciona muita coisa à equipa de projeto, até por que alarga a capacidade de talento que pode ser selecionada para o projeto. Os gestores de projeto devem aprender a tirar o máximo desta oportunidade e aprender ainda a gerir trabalhadores remotos para a direção certa.

Começar os projectos com o pé direito

A preparação é uma parte chave na gestão de projecto. Se o projecto não começar de forma correcta irá ter problemas como refazer o trabalho, O âmbito indeterminado, atrasos no plano, má estimação, etc. Embora alguns pensem que o importante é saltar para o trabalho com as duas mãos, o gestor de projecto precisa de ajudar a oferecer um ponto sólido de partida para o projecto. Este ponto de partida é que muitas vezes determina se o projecto vai ou não ter sucesso, representa o ponto de partida do projecto e da equipa, e merece todo o tempo e esforço que se faça para garantir que se apoia em sólidos alicerces. Não se pode saltar às cegas para qualquer coisa que não está perfeitamente compreendida pela equipa.
 

O âmbito

A gestão do âmbito é uma parte importante da gestão de projecto. Muitos projectos iniciam-se com a visão de uma pequena cascata e os stakeholders acabam a dizer que querem as Cataratas Vitória. A gestão de âmbito irá ser uma parte da gestão de projecto ao longo de toda a sua vida, mas há alguns passos que o gestor de projecto deve tomar no início para minimizar as questões com o deslizar do âmbito.

O primeiro passo é definir o âmbito para o projecto; esta definição não tem de ser muito detalhada, mas tem de ser compreendida por todos os envolvidos. O segundo passo (e muito mais difícil) é obter aprovação formal para o âmbito. Esta assinatura pode ser de um documento legal ou pode ser um acordo entre o sponsor e o gestor do projecto. Em qualquer dos casos, é necessário sublinhar para todos que se o âmbito for alterado terão de haver alterações do projecto. A definição de âmbito deve ser claramente compreendida antes de começar o trabalho ou existirão problemas no futuro.
 

Baseline

Depois de o âmbito ter sido definido e acordado pode então ser desenvolvido um rascunho dum plano base. Este não terá de incluir todas as pequenas actividades que serão realizadas pela equipa do projecto, mas deverá incluir as milestones chave e o desenho de como o trabalho do projecto será executado. Esta baseline inicial será o primeiro passo para o plano completo do projecto que será desenvolvido e actualizado durante o projecto. Tal como o âmbito, esta baseline preliminar deve ser compreendida e formalmente acordada pelos stakeholders e o sponsor do projecto antes que o trabalho do projecto se inicie. Conforme esta baseline inicial vai sendo desenvolvida, o gestor do projecto deve apresentar e definir como serão os status do projecto apresentados ao sponsor do projecto durante a sua execução.

 

Organização da equipa

Um último ponto que deve ser compreendido cobre a equipa que irá trabalhar no projecto e que é a necessidade de estabelecer a forma de funcionamento da equipa. Dê a conhecer a todos os recursos quem é que está na equipa e quais são as suas funções nesta. É muito importante comunicar quem será responsável por quê e como prestará contas desta responsabilidade ao gestor de projecto.

Ser aberta e honesto acerca do trabalho do projecto e como o projecto será gerido é o melhor caminho para pôr, de imediato, a equipa do projecto a colaborar. Fazer com que a equipa de projecto esteja motivada de início para o trabalho do projecto passa assim por todos conhecerem as funções e as responsabilidades mútuas.

Kenneth Darter e LQ

Razões para falhar a mudança

As iniciativas de mudança nas organizações, como a implementação de processos novos ou alterados ou a utilização de novas aplicações para processos de negócio, falham muito mais vezes do que os responsáveis gostariam, mas isso é uma característica destas actividades que não deixa de acontecer só por que queremos. Há algumas razões principais que fazem com que estas iniciativas falhem e se as conhecermos talvez consigamos gerir e utilizar a nosso favor.

 

Uma visão pouco clara

A mudança atinge todos. Temos de fazer com que a visão para a nossa mudança seja mesmo muito fácil de entender para que toda a gente compreenda. A criação de uma visão clara significa trazer para cima da mesa aquilo que se pretende mesmo atingir. Se é implementar um processo para a gestão de projecto ou se é melhorar as taxas de sucesso dos projectos? Será que é a generalização de ferramentas de gestão de projecto como o Primavera P6 ou a recolha de melhores dados para gerir os custos dos projectos?

Uma das formas de garantir que a visão é clara é estabelecer como é que sabemos que alcançamos o propósito. Pense nas métricas que pode utilizar e que o ajudem a avaliar qual a proximidade para o seu objectivo. Conhecer como é que o sucesso se apresenta ajuda toda a equipa a trabalhar com efectividade na sua direcção.

 

Comunicação deficiente

Se perguntar qual é o maior factor de risco de uma iniciativa de mudança a resposta é: as comunicações. Algumas companhias até são muito boas a comunicar de cima para baixo e assim os projectos de mudança são lançadas com banda de música e foguetes. À superfície, pelo menos, todos sabem o conteúdo da última newsletter do projecto e como o trabalho deles irá contribuir para os objectivos gerais.

Mas a comunicação funciona nos dois sentidos. Para cima a comunicação é também importante. A comunicação das pessoas afectadas pela mudança para aqueles que a estão a implementar. Como estão as coisas a correr na linha da frente? Somente com métodos de comunicação efectiva para reunir o feedback é que quem dirige o projecto sabe como é que a mudança está a ser entendida – e, assim, se irá mesmo ser possível alcançá-la.

 

Falta de apoio na cultura da organização

A implementação de uma estrutura de processos numa companhia com uma cultura aberta e em rede irá funcionar com muita dificuldade. De igual forma, uma função de gestão de projecto altamente colaborativa sem apoio em metodologias estruturadas irá lutar para ter sucesso nas indústrias reguladas dos nossos dias. As grandes ideias de mudança são só início da viagem!

Teremos de conseguir que a forma como iremos implementar forneça um novo modelo de cultura para o negócio. Se não o conseguir, então mude, em primeiro lugar, a cultura.

 

Falta de direcção de topo

Infelizmente isto acontece todo o tempo e em todo o lugar. O responsável executivo da liderança da iniciativa muda de posição na companhia ou perde o foco e, no final, a mudança falha. Tem de haver sempre alguém no topo como proprietário da mudança e decidindo acerca da direcção das actividades que esta exige para ser alcançada. Esta pessoa é aquela que explicará aos colaboradores nas reuniões por que é que a mudança é tão importante. Será responsável, claro, pelo orçamento e prestará contas pelo resultado alcançado. Se perdermos o líder da mudança, considere parar o processo de mudança – pelo menos até conseguir encontrar outro executivo que funcione como campeão da mudança.

 

Declarar o sucesso demasiado cedo

Contratar um director não é um sucesso. Instalar o novo software não é um sucesso. Muitas iniciativas de mudança enfraquecem e morrem porque se instala um estado de «deixar andar». Há muito mais para fazer o sucesso de uma mudança do que o ligar de um interruptor. Nos dias iniciais a novidade pode ser suficiente para obter alguns benefícios, mas com o tempo, a não ser que haja apoio, as pessoas voltam às velhas formas de fazer as coisas.

Não desmobilize a equipa da mudança demasiado cedo. Assegure-se que a mudança transitou de facto para o negócio como a forma usual de fazer as coisas e resolva todas as questões que sejam colocadas. O melhor é descontinuar totalmente as formas antigas de os colaboradores fazerem as coisas. Os campeões da mudança de cada equipa podem ajudar porque podem descobrir lacunas e apoiar os colegas.

Mas o conselho mais importante é pensar naquilo que, no final, queremos alcançar. Se conhecemos o objectivo final, aquilo por que estamos a trabalhar, articulando e comunicando com outras pessoas torna-se muito mais fácil. Planeie para o estado final, garanta que sabe o que é que você quer e torne possível a todos realizarem a viagem até lá consigo.

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.

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.

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.

É 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.

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.
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

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 uma 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

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?

A 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

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.
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.

Não é o Processo que Falha na Realização durante a crise

Devemos compreender que, durante uma crise, não é o processo que falha. O fracasso é causado por uma sobre confiança num processo excessivamente prescritivo. Neste esforço para adoptar disciplina e rigor de processos, as organizações de TI adoptam muitas vezes uma abordagem de desenho de processos muito prescritiva. O desafio é que quanto mais prescritivo é um processo, mais complexo este se torna. Se tenta responder a muito pequenas acções então vai ter de avaliar todas as acções possíveis. A complexidade consequentemente limita a sua capacidade.

Muito embora um processo altamente complexo e prescritivo possa funcionar num ambiente muito previsível, este não é, no entanto, o ambiente normalmente encontrado pelas organizações de TI.

Mas, se estes são os processos altamente prescritivos e complexos que a organização de TI implementou, então quando ocorre uma crise, a taxa e volume de actividade simplesmente submerge a capacidade deste processo altamente prescritivo. Mas, sublinha-se, não é o processo que falha. Se o processo tivesse sido construído dentro da assumpção que os seus executores não necessitavam daquele alto nível de prescrição, poderia ser suficientemente simples pra ser escalado e enfrentar o volume que a crise gerou.

Isto conduz-nos ao cerne do problema: as organizações de TI constroem processos altamente prescritivos e complexos porque não confiam nas competências de liderança e criatividade dos seus executores.

Criar Competências de Liderança e Criatividade

É essa diferença na confiança que conduz ao fracasso do processo durante a crise. Ironicamente, a falta das competências de liderança e criatividade que conduzem a um processo demasiado prescritivo são também as duas mais importantes competências necessárias para gerir com efectividade durante uma crise. O desenvolvimento destas duas competências não só irá permitir a construção de processos que não se baseiam em elementos demasiado prescritivos, mas fornecerão à organização as capacidades que esta necessita para poder responder durante uma crise.

A criação destas competências de liderança e criatividade assenta nas seguintes três bases fundamentais:

• Desenvolver o propósito operacional
• Embeber o valor do Negócio como a base para o paradigma de decisão
• Criar uma cultura de responsabilidade e aptidão.

Análise de Negócio numa Equipa Agile

Os processos, produtos e relações alteram-se numa equipa Agile.

Como planeamos o trabalho, entregamos o produto, representamos os requisitos, partilhamos o conhecimento, interagimos com a equipa e cliente, gerimos os requisitos em mudança e documentamos os requisitos será completamente diferente dos projectos tradicionais em Waterfall.

De facto, pass a fazer parte de uma equipa de colegas altamente colaborativos com um foco furioso em realizar valor, negociando a realização de valor em ciclos curtos e apoiando os parceiros de negócio para compreenderem o que realmente necessitam, não só no imediato, mas também conforme o produto vai aparecendo em pequenos pedaços utilizáveis.

Que muda

Os analistas de negócio devem ceder o controlo dos requisitos, a relação com o cliente e a documentação usual de requisitos. Porquê? Só porque na equipa Agile você entrega software valioso a trabalhar numas poucas semanas. E você (a sua equipa e o seu cliente) não sabem qual será exactamente o produto final mesmo até ao momento em que se começa a construí-lo, entrega-lo e obter, então, feedback sobre ele. Só então apreendemos qual é a real necessidade.

Um projecto Agile é tudo acerca de suspender o controlo durante tanto tempo quanto o possível.

Até as funções da equipa podem ser ambíguas: As especificidades podem variar, mas uma equipa Agile colabora para entregar um conjunto de requisitos a que se comprometeu. Cada membro da equipe está pronto, mesmo ansioso a fazer o que for preciso para que isso aconteça, não importa o que ditarem as responsabilidades oficiais do trabalho .

É provável que não seja o único a elicitar, analisar e especificar requisitos. A equipa está focada em entregar um software «utilizável» em ciclos curtos (iterações), assim as suas actividades podem cruzar sobre outras actividades que entusiasmam as suas competências, capacidades e interesse.

Por exemplo, é pouco provável que você se identifique ou mesmo crie e execute testes de aceitação do utilizador: a validação em cima do produto. As suas competências soft e a compreensão das dependências dos requisitos tornam-no um bom candidato para realizar o planeamento de workshops de definição do mapa de trabalhos do produto e planos de release.

Como Analista de Negócio Agile você deixou de estar preso à grande e complexa documentação de requisitos e modelos. Em vez disso, vai influenciar os seus parceiros de negócio e equipas a repensar que tipo de (e quanta) documentação é necessário. Você pode entregar a documentação em pequenos pedaços, juntamente com os pequenos e úteis pedaços de requisitos que a sua equipa de entrega em cada iteração (muitas vezes sob a forma de user stories). Você pode passar a desenvolver uma documentação leve de produto, de utilizador ou de suporte.

Novo tipo de trabalho

O seu trabalho é, ao mesmo tempo, táctico e estratégico: você tem de entender o ponto de vista global (o mapa de visão do produto e os planos de release), mantendo ao mesmo tempo uma mão firme no agora (a iteração corrente). Tem de ter a disciplina e a flexibilidade para operar em modos múltiplos (o «agora» da iteração corrente e o «depois» das próximas iterações.

O seu trabalho será transparente. Você obterá melhores estimativas e ao trabalhar com seus companheiros da equipa multifuncional pode prever com segurança quanto o software a sua equipa pode entregar em cada iteração. A visibilidade de planeamento da iteração, as demonstrações de final de iteração, e as retrospectivas não permitem permitir nenhum esconso. Você vai sentir-se mais em controlo, já que vai ser abertamente responsável perante seu cliente, a equipe, e você próprio.

Luís Quintino