COMO CRIAR RELATÓRIOS DE PROGRESSO

 Os relatórios de status do projeto são difíceis de escrever. É um facto que os gestores de projeto podem reunir-se e chegar a acordo em diferentes indústrias. Mas, embora possa ser difícil montar um documento que tenha o tom certo para o público, tenha as informações pertinentes discutidas na profundidade apropriada e possa ser funcional em vez de apenas informativo, os gestores de projeto são encarregues de fazer exatamente isso durante todo o ciclo de vida de um projeto. É por isso que dominar a técnica é tão crucial. Mas é aquela que ninguém nunca te ensina a fazer.

Se sente que está se atrapalhando no escuro tentando montar um bom relatório de status do pprojeto, não procure mais. Aqui está um guia que irá ajudá-lo a criar um modelo eficaz que pode ser usado repetidamente.

A sério.

Não importa em que setor esteja:  um prazo é um prazo em todos os lugares. Por isso, esse método infalível de relatar o status de projetos em andamento é aplicável a qualquer tipo de área. Aqui estão os aspetos mais importantes dum relatório de status do projeto – a anatomia, se você quiser – e por que eles são importantes.

• Vá direto ao assunto. Todo o trabalho de um relatório de status do projeto é atualizar o leitor sobre o que está acontecendo com um projeto, relação cliente/fornecedor específico. Até este ponto, é imperativo que chegue ao ponto cedo. Isso é verdade se estiver numa reunião de status em conjunto com o relatório ou simplesmente enviando o relatório para revisão executiva. Pense em como se sente quando tem que verificar contratos em busca de detalhes que devem ser abordados. O seu público vai sentir o mesmo – eles vão querer o «fiambre» e vão querer imediatamente.
  Prepare um resumo executivo na parte superior do relatório. Esta seção descreverá o que será encontrado em mais detalhes mais adiante no documento. O público, então, tem a oportunidade de ler essa parte primeiro para acompanhar o progresso e retornar à seção mais detalhada em data posterior.

• Conheça o seu público. Ao começar este mergulho profundo nos problemas em questão, considere o público. Eles precisam saber as porcas e parafusos do que está a acontecer. Quanto mais detalhes sobre isso, melhor. Se o relatório vai para a equipa executiva, talvez não. Algumas das minúcias podem ser deixadas de fora do status e a verborreia pode ser reforçada.

• Reduza o embelezamento. Outra coisa a ter em conta é o tipo de informação que reporta. Descubra que tipo de informação será importante para o leitor e reduza a tagarelice periférica.

• Deixe que as suas atualizações contem uma história. Um relatório de status do projeto é um documento dinâmico. Com isso em mente, certifique-se de que seus segmentos estejam divididos por problema/preocupação/milestone. Abaixo de cada cabeçalho, adicione novos comentários com a frequência acordada, mantendo o anterior atualizado abaixo do mais recente. Ao fazer isso, está a permitir que o leitor veja o progresso geral. Isto dar-lhe-á algo tangível de referência caso um atraso faça descarrilar o progresso no futuro.

• A matéria de topo também é importante. Certifique-se de que tem a data e a hora das reuniões do relatório de estado do projeto (se as tiver) na parte superior do relatório Liste os participantes esperados do lado deles e do seu lado para que todos saibam quem são os interessados. Esta informação pode revelar-se importante caso haja necessidade de reunir todos na sala para resolver uma preocupação mais à frente.

• Mantenha uma lista de itens de ação em execução. Uma reunião de status pode revelar novas variáveis para trabalhar no projeto. Mantenha uma lista de itens de ação em execução para mostrar o que surgiu e quem é responsável por resolvê-lo.

• Mantenha-o curto e doce. Embora duas páginas não pareçam curtas, está no mundo dos relatórios de status do projeto. Em teoria, não deve ter problemas ou preocupações contínuas que se estendam por duas páginas – isso indica que nenhum progresso está sendo feito. Como um relatório de status do projeto é uma ferramenta usada para atualizar as pessoas sobre as coisas, ele também não deve funcionar como seu plano de projeto.

Estas etapas ajudarão a criar um relatório de status do projeto. Será uma atividade plug and play, removendo efetivamente todas as suposições e dando-lhe um modelo que é versátil e simples.

A Gestão do Portfólio de Serviços é mais importante que a Gestão do Portfólio de Projetos

de IT Skeptic

Há uma visão essencial que poucas vezes é referenciada na ITIL e ainda menos vezes compreendida que é a Gestão do Portfólio de Serviços.

Como trabalhamos numa área em que defendemos, vendemos e implementamos processos e soluções de Gestão de Portfólio e de Projetos este artigo saltou-nos à vista e decidimos traduzi-lo com mínimas adaptações. Corresponde a uma visão integrada destes fenómenos que partilhamos.

Demasiadas organizações têm uma visão portfólio em que apreciam apenas programas e projetos, enquanto negligenciam os sistemas em operação. Este é uma ordem removida de uma visão verdadeiramente holística. A Gestão de Portfólio e de Projetos só olha para a mudança, e não para o status atual. A Gestão de Portfólio de Serviços (SPM) olha para os serviços em produção bem como às propostas mudanças de serviço. 

SPM olha para os serviços em produção, bem como as alterações propostas ao serviço. Olha para a distribuição de recursos entre ambos o Construir (Build) e o Executar (Run), e não apenas Construir. O SPM considera o impacto sobre os nossos serviços existentes quando tentamos introduzir novos serviços. Esta é uma abordagem brilhante. É essencial. Não fazer isso é a razão por que muitos departamentos de TI estão sempre afogados em projetos.

A incapacidade de gerir todo o portfólio de serviços correntes e planeados - concentrando-se apenas na carteira de mudança - significa que haverá um dilúvio contínuo das despesas de investimento (CAPEX) sobre os novos serviços com zero de consideração da capacidade de RUN para os absorver (e muitas vezes, orçamento de zero para os fazer).
Este martelar teimoso é agravado pela prática moderna de retirar os recursos para fora do RUN e atribuí-los aos projetos sem considerar adequadamente o impacto sobre o RUN. Nós entramos em autofagia e consumimos os nossos recursos, destruímos a nossa capacidade de realizar os serviços, porque estamos tão ocupados em construir e mudar os serviços.

O balanceamento de prioridades e recursos em todo o portfólio de mudança, de projetos e de programas, não é suficiente. Temos de equilibrar entre todas as atividades, através BUIL e RUN em conjunto. A Estratégia de Serviço ITIL diz-nos isso através do SPM. É uma pena, poucas pessoas o leiam e menos ainda o tenham obtido. A gestão do Serviço de TI é um equilíbrio constante entre o BUILD e o RUN, ou como eu gosto de definir para proteger e servir (OK OK talvez isso não seja o melhor slogan para usar agora, mas aceitem a ideia). 

Em muitas organizações, o PPM é tratado como uma prática estratégica e ferramentas de PPM são vendidas para os executivos. PPM não é estratégico: é uma tática para o PMO da Empresa gerir as tarefas que lhe foram dadas com as técnicas que criaram. Por outro lado, a Gestão do Portfólio de Serviço, este é que é estratégico.

Espere! Ainda há mais. A Gestão do Portfólio de Serviços oferece uma visão holística de tudo o que acontece na área de TI. Pense nisto: isso faz com que o SPM seja um dos principais mecanismos de comunicação entre a empresa e as TI. O SPM é como nas TI articulamos a nossa posição, a nossa capacidade, os nossos desafios, as nossas necessidades em termos de negócio. O SPM é como solicitamos decisões e direção do executivo e da governação e seus pares sobre como alocar o nosso esforço e os nossos recursos. É como justificamos mais recursos. 

Qual é o mais importante desafio para as TI no momento? Sem dúvida que é a falta de uma boa governação de TI (a menos que seja um fornecedor a contar a história, caso em que o maior problema é, naturalmente, qualquer que seja que a sua ferramenta resolve ou pode ser feito para parecer resolver). Esta é uma questão tão importante!

Se a governação das TI é o desafio e questão mais importante, então o SPM é uma das mais importantes práticas e o portfólio de serviços um dos artefactos mais essenciais. Então porque é tão raro?
Ver em Inglês aqui.

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? 

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.

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.

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.

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.

A Mudança e Liderança

A liderança é uma coisa que não existe em abundância na maioria das organizações. Se está a ler isto, provavelmente, já faz parte dum grupo exclusivo de pessoas preocupadas com a liderança ou é mesmo um líder – porque só um líder procura constantemente novas formas de melhorar. Este texto corresponde a uma reflexão que usualmente comunico em formação.

A liderança de um esforço de transformação exige todas as competências de liderança que tem e estas devem ser aplicadas com determinação para serem efectivas neste contexto. A razão para isso, em muitos casos, é porque a liderança é muito simplesmente acerca de visão e confiança. Estabelecemos a direcção e movemo-nos nesse sentido com confiança e a equipa segue-nos. Embora isto seja um ponto crítico do que é necessário realizar, um esforço de transformação numa organização é tanto acerca de construir líderes como acerca de liderança.

Para realizar um esforço de transformação com sucesso são necessárias várias coisas. Hoje falamos de como nos tornarmos um Campeão da Mudança.

A primeira coisa e também a mais importante para nos tornarmos num líder da transformação é sermos o corpo e a alma da mudança. Uma das maiores barreiras da mudança é a inércia simples.

A estrada da modernização das estruturas está juncada dos esforços abandonados de propósitos falhados de mudança. Não podemos culpar ninguém por acreditarem em que a verdadeira mudança nunca ocorre, mesmo na nossa equipa.

Precisamos de mudar isto

Selecione algo pequeno, mas significativo, em que exige que mude a forma como opera e mude-o – de forma pública. Pode ser, por exemplo, que quer ser chamado sempre que se declare um Incidente de Maior Dimensão – qualquer que seja o dia ou a hora. Talvez possa ser que agora irá pessoalmente aprovar qualquer Mudança importante ou que irá pessoalmente dirigir a Reunião de Revisão de Incidentes de Maior Dimensão e que irão concentrar-se nas falhas dos processos e não nos esforços heróicos. Qualquer que seja, deve:

·         Afetá-lo pessoalmente e exigir que force de forma óbvia e visível uma alteração de comportamento

·         Exigir um investimento pessoal da sua parte – não pode ser simples e conveniente

·         Ser significativo – não pode ser só de fazer figura.

Inicia-se aqui um processo de construção apoiada da confiança na mudança.

Mas ainda é necessário muito!

O propósito é enviar uma mensagem de força à sua equipa de que a mudança está realmente a chegar – e que está a começar consigo. Diga-o, sempre que tem uma oportunidade, e faça por que a sua equipa compreenda como está empenhado de forma séria neste esforço.

Financiar e Mostrar

Uma das actividades tácticas mais importante que deve ser realizada é financiar o esforço de transformação. Claro que isto até parece óbvio, por que todos sabem que uma mudança custa recursos – humanos e financeiros -, mas o que necessitamos é muito mais do que dar ao programa o dinheiro que ele precisa. Financiar é um símbolo muito poderoso para aquilo que a Liderança valoriza. Muitos programas de transformação tiveram uma morte dolorosa porque tornaram-se só esqueleto sem nenhuma carne. Apesar de falarmos e empolgarmo-nos, quando chega a hora de andarmos para a frente, o financiamento não se materializa. Isto é como quando um papagaio deixa de ter vento e cai, o que envia uma mensagem à equipa de que a liderança não valoriza o esforço realizado tanto como dizia e que afinal não falava seriamente da mudança.

Temos de evitar a sina triste do público financiamento do esforço. Esta acção significa de facto duas coisas. Primeiro, que temos de ser realistas acerca do que irá ser necessário. Reconhecer que a maioria esmagadora da «despesa» vais ser o tempo dos vossos colaboradores internos. Mas com base nos objectivos de transformação, pode ser que necessite de alguma consultoria externa, o aumento de alguns recursos para libertar a equipa e, ainda algumas ferramentas.

Seja lá o que necessita, não seja tímido. Obtenha o financiamento. Se não quer fazer agora e falhar, então espere até que esteja pronto e seja garantido.

Lançar um esforço de transformação sem financiamento e pela declaração simbólico que isto representa é certamente uma receita para o fracasso.

Com o financiamento garantido, faça um farol dele.

Faça reuniões. Envie emails. Faça sms em broadcast. Envie, enfim, uma mensagem em alto e bom som e clara que este esforço é uma das suas mais importantes e críticas prioridades. Assegure-se que toda a equipa sabe que financiou este esforço com a quantia adequada – e isso é muito importante. Não pode haver dúvidas e não podemos fracassar. Torne claro para todos que este esforço de mudança irá ser conseguido.

Proteger e Gerir

O esforço de transformação foi então financiado e a equipa segue a liderança após um primeiro empenho na transformação. Todos conhecem as áreas a mudar, mas agora o papel do líder da transformação tem de evoluir.

Conforme o esforço é desenvolvido a liderança altera-se para uma função de Protecção, visto que o esforço de transformação estará, na sua fase inicial, numa situação frágil e, mesmo nas melhores organizações, haverá um pequeno exército de pessoas a tentar de forma consciente ou subconsciente miná-lo.

As pessoas têm medo da mudança. Se damos corpo à mudança e obtivemos financiamento para ela e fizemos uma demonstração pública disso, as pessoas começam a receber uma mensagem de que a mudança está a chegar. Isto pode criar ansiedade e incerteza e levar a que alguns dos membros da sua equipa tomem decisões irracionais. Tem de proteger o esforço de transformação e dar-lhe tempo para ter sucesso.

Há duas coisas críticas que deve fazer para proteger o esforço:

• Respeite as Decisões da Equipa de Projecto: Uma forma de minar o esforço de transformação é colocar em questão as decisões da equipa do programa. Embora ninguém deva ter receio de feedback construtivo, devemos resistir à tentação de substituir as equipas do programa por razões de maior eficácia, por exemplo. Se alguém à sua volta levanta uma questão relacionada com o programa, dirija-o para a equipa do programa e a sua estrutura de direcção para solucionar a questão. Se puser em questão a autoridade da equipa do programa a mudança não irá surgir.
  
• Suporte o esforço da gestão do dia-a-dia: Muito mais do que ultrapassar as decisões, deve procurar utilizar todas as mudanças que surgem do programa e embebê-las nas suas práticas de gestão diárias. Será que o programa criou novas métricas? Então reveja-as como parte das suas reuniões de revisão operacional. Foram implementados novos critérios de mudança? Peça que as restantes mudanças feitas sigam os mesmos critérios.

O seu suporte continuado e visível ao esforço será crítico para o seu sucesso de longo prazo. Pode ser facilmente ficar cansado pelos esforços de gestão do dia-a-dia e ficar com a percepção que já fez tudo para suportar o esforço. Mas não. Exige-se que de forma consciente pense em que forma visível poderá dar ao esforço um maior peso de apoio todos os dias. Respeitar decisões, embeber os resultados no trabalho do dia-a-dia, aparecer nos eventos do programa, oferecer encorajamento pessoal aos membros da equipa – todas estas acções dar-lhes-ão suporte e protecção que eles necessitam para terem sucesso no esforço de mudança.

Deixe-os falhar (mais ou menos!)

A última coisa que deve fazer para liderar efetivamente um esforço de transformação é o mais simples e mais difícil - você deve deixar a equipa passar pelo ciclo de tentativa e erro. E isso significa que algumas das coisas que eles fazem falharão.

A transformação organizacional pode ser confusa. Não segue um plano de projeto simples. Como um dos principais objetivos é criar uma nova geração de líderes na organização, deve capacitá-los para liderar esse esforço e dar-lhes a latitude necessária para executá-lo. Devem ter permissão para experimentar e assumir riscos sem medo de recriminação. Isso significa que deve romper o véu corporativo da infalibilidade e celebrar a transformação da organização quando ela for bem-sucedida e quando falhar - desde que a falha seja usada como uma oportunidade para continuar e melhorar a organização.

Embora isso possa ser muito difícil, muitas vezes é durante os esforços fracassados que a equipa aprende mais sobre como realmente mudar a organização. E isso leva a resultados explosivos e exponenciais. Deve sempre reagir severamente ao fracasso causado por esforços desinteressados ou manobras políticas, mas o fracasso resultante da tomada de risco e uma tentativa séria de melhorar a organização deve ser aceite e até celebrado por que isso permitirá que a organização continue amadurecendo.

Construir a Geração de Líderes

Ao adotar estas quatro características e se tornar um verdadeiro líder de transformação, será capaz de alcançar resultados significativos para a organização. Talvez o impacto mais duradouro desta abordagem, no entanto, seja o legado de liderança que deixará para trás.

O tipo de apoio que isso requer tem o efeito de criar confiança nas equipas. Os seus colaboradores verão que a verdadeira mudança pode ocorrer e encontrarão em si mesmos traços de caráter que eles podem não ter conhecido. Eles tornar-se-ão mais ousados na paixão para tornar a organização melhor. Eles sentir-se-ão empoderados de que podem fazer a diferença. E sentir-se-ão investidos de que não são meramente uma engrenagem nas obras, mas um participante ativo na definição do futuro da organização. Eles tornar-se-ão uma geração de líderes que lhe permitirá acelerar os esforços e obter resultados de negócios impactantes nos anos vindouros.

Luís Quintino

Tipos de risco em projetos de construção

Tudo o que deu errado num projeto de construção é um risco potencial no próximo projeto. Muitos gestores de projeto desenvolvem instintivamente uma lista de riscos históricos e lições aprendidas e tomam medidas para minimizar a exposição a esses riscos no futuro. A importância de pensar na contingência como forma de enfrentar o risco conduz-me a desenvolver estas linhas sobre riscos em projetos de construção.

Os riscos variam de acordo com a indústria e até pelo tipo de projeto de construção, bem como pelo pessoal envolvido com o projeto. Um projeto de autoestrada ou ponte tem um grupo diferente de riscos do de uma instalação ou prédio, e os contratados selecionados podem ter diferentes graus de influência sobre o nível de riscos para o desempenho. Este é o primeiro tópico em que se deve basear a análise.

Riscos diretos

Se um dono de obra tentar economizar dinheiro em serviços de pré-construção, limitando a extensão da investigação de campo ou o desenvolvimento de dados executados, haverá um risco maior de descoberta tardia de problemas desconhecidos. A experiência e competência dos arquitetos e engenheiros que lidam com o desenho do projeto, bem como o seu controlo de qualidade no desenvolvimento de desenhos de trabalho, afetam diretamente o esforço de construção e, consequentemente, o risco associado aos planos e especificações.

Mesmo que o dono de obra tenha sido proativo na investigação pré-construção, há sempre o risco de condições imprevistas. Isso pode ser uma função do tipo de solo encontrado, do município do local e da sua cultura e histórico de manter bons registos de equipamentos obsoletos. Se a cidade na qual o projeto será construído tem um histórico de exigir que os empreiteiros removam todas as linhas subterrâneas abandonadas, há um risco muito menor de conflitos subterrâneos.

Riscos internos

A seleção da equipa do projeto pode impactar positiva ou negativamente na probabilidade de conclusão do projeto com sucesso. Os projetos que criam propostas que usam filosofias de aquisição permitindo que todos os contratados com capacidade financeira participem, provavelmente experimentarão um nível muito mais alto de risco para desempenho pontual do que uma filosofia de aquisição que requeira qualificação dos contratados propostos para garantir que eles tenham a experiência apropriada e recursos para construir o projeto. Um único subcontratado fraco num projeto aumentará o risco de desempenho e exigirá mais gestão do que o previsto. Se isso não for considerado, todos ficarão surpresos quando o subcontratado falhar e precisar aumentar ou corrigir o trabalho. Problemas relacionados com a gestão e possível rescisão de um subcontratante em falha causam geralmente sérios impactos negativos no projeto.

A reputação do gestor de construção (CM), bem como a cultura corporativa afetará o desempenho do projeto. Se o CM definir o sucesso com extensões de tempo mínimas como o único benchmark, provavelmente haverá mais conflitos e maior necessidade dos esforços de resolução de reclamações. Além disso, as capacidades de gestão do CM afetam diretamente muitas atividades do projeto, como a revisão de desenhos de trabalho e a resposta a solicitações de informações por forma a resolver questões sobre a construção.

O trabalho de fora ou de terceiros pode acarretar riscos significativos de influência no sucesso do projeto. Por exemplo, uma estação ferroviária ligeira a ser construída no topo de um parque de estacionamento em construção por um contratante diferente correrá um risco acrescido de conclusão em tempo. O projeto não tem controle sobre - e pouca capacidade de influenciar - a conclusão do estacionamento, que rapidamente se torna vital para a conclusão do projeto do metro ligeiro.

Riscos externos

A maioria dos projetos é afetada pelas condições meteorológicas locais, que, quando adversas, podem impedir significativamente o progresso. A maioria das especificações exige que o empreiteiro leve em consideração as condições climáticas locais normais no planeamento, o que inclui condições climáticas adversas normais, mas também permite extensões de tempo quando ocorre um clima adverso incomum. As melhores práticas exigiriam que o contratado pesquisasse os registros meteorológicos históricos locais para planear as condições climáticas médias de três a cinco anos. Diferentes partes do país e do mundo têm uma grande variação nas condições climáticas, portanto, planear ou não planear o risco do clima local pode afetar significativamente o sucesso do projeto.

Situações políticas locais, especialmente em climas políticos voláteis, podem dificultar todos os esforços para construir um projeto de forma eficiente. Países com sistemas políticos ou económicos instáveis ​​terão maiores riscos na conclusão de projetos bem-sucedidos do que aqueles com sistemas mais estáveis. Países ou regiões sujeitas a guerras, terrorismo, turbulência ou outros tipos de violência também correm maiores riscos para o sucesso do projeto do que outros. Se a administração local tiver uma política de exigir uma investigação profunda sobre questões ambientais ou burocracia rigorosa ou complicada, os projetos construídos nessa localidade terão um risco maior de licenças atrasadas e conflitos durante a construção.

Riscos de reputação

Outro grande risco em qualquer projeto é a experiência e a reputação da equipa do projeto para práticas seguras de construção. Violações de segurança e acidentes podem encerrar completamente uma obra. Mesmo pequenas falhas de segurança podem distrair a equipa do projeto e impedir o desempenho oportuno. Se um contratado tiver um histórico de segurança insatisfatório, o risco de atrasos por causa de violações de segurança é aumentado e deve ser levado em consideração durante o desenvolvimento do cronograma.

Em suma

Sem um cronograma de linha de base de caminho crítico bem projetado e desenvolvido, um processo de gestão de riscos não será efetivo. A análise de risco depende de cálculos precisos e consistentes da lógica da rede, da adequação do sequenciamento e das fases e de uma abordagem razoável para estimar as durações das atividades. O cronograma tenta prever quanto tempo levará para concluir uma atividade em algum momento desconhecido no futuro, com uma composição de equipa mais ou menos conhecida, com experiência variável e a trabalhar em condições desconhecidas.

A gestão de riscos reconhece a incerteza na estimativa de duração e fornece um sistema para debater estes e outros riscos que podem ocorrer durante o projeto. As distribuições de probabilidade são a melhor maneira de modelar as durações das atividades planeadas e um dos primeiros métodos usados de gestão da incerteza.

Documentar Corretamente as Decisões num Projeto de Construção

"Por favor, prossiga com as mudanças."

Essa frase familiar usada por muitos, mas não escrita ou documentada corretamente, pode causar grandes problemas. A documentação das decisões nos projetos de construção não apenas economiza tempo e dinheiro, mas também deve ser uma prática recomendada em todos.

Existem muitas ferramentas e recursos para usar e capturar decisões ou compromissos importantes, mas o que é considerado como tal? Como pode preparar-se para uma reclamação ou situação em potencial que precisa de documentação? Vamos sugerir algumas informações sobre como documentar adequadamente as decisões em projetos de construção.

O que são considerados «documentos importantes»

Para começar, precisamos definir o que podemos considerar como documentos importantes.
 

Plantas, desenhos de engenharia, e-mails, âmbito de trabalho e propostas são itens críticos que devem ser mantidos por muitos anos. Uma ótima maneira de alcançar o processo apropriado de retenção de documentos é usar sistemas para acompanhar as alterações e documentos. No entanto, às vezes é importante acompanhar e entender o contexto do diálogo. As cópias folha de pagamento e as coberturas do seguro também podem fazer parte dessa lista e as cópias originais das mesmas devem ser mantidas por um período maior de tempo.

Documentar as decisões

Em primeiro lugar, é imperativo estabelecer um plano de comunicação para garantir que as partes interessadas certas estejam conscientes e sejam notificadas das decisões. A decisão simples, como pequenas alterações no âmbito, é capturada por meio de comunicações informais, como cartas ou e-mails, antes de serem formalizadas e é assim, evidenciada-
 

Os ajustes do contrato precisam seguir a proposta e o âmbito é esclarecido, debatido e aceite por todas as partes, entre outros itens-chave relativos ao seu projeto. São todas estas coisas que se repetem e que devem ser documentadas.

Documentação de proposta e de Âmbito

Durante o processo de pré-licitação e pré-construção, muitas decisões são tomadas. São recebidos e-mails ou participará em teleconferências sobre quais novos âmbitos ou esclarecimentos são feitos e, assim que possível, precisará adicionar essas alterações ao âmbito e compartilhar essas informações com o dono do projeto ou o seu representante.

O processo de documentação deve conter estimativas, orçamentos, retiradas, informação de preços unitários, ofertas de fornecedores e encargos de trabalho que suportam os ajustes necessários.
 

Documentar as datas de quando você recebeu aprovação para emitir um pedido de compra é importante se precisar comprovar atrasos no material ou nos pedidos de compra associados às decisões. A documentação correta exigida para materiais e compras deve incluir a data de aprovação do material, pedido de compra e um documento com a data de entrega que o fornecedor está a indicar.
 

Para documentar essa decisão, o pedido de compra deve referenciar ou estar vinculado a uma seção específica do contrato e da especificação. Certifique-se de que o aprovador recebe e assina uma cópia, assim como o proponente, com anotação da data de aprovação e da data de entrega.
 

Isto merece uma atenção especial. Toda a vez que uma decisão importante é tomada, é imperativo registar ou produzir um instantâneo do cronograma real, documentando em que momento a decisão foi tomada.
 

Esse instantâneo pode servir como referência para documentar quaisquer mudanças no cronograma que são necessárias após a decisão. Neste ponto, o cronograma deve ser estabelecido e guardado em conjunto com a documentação exigida que fez parte do processo de decisão. Além disso, capture uma comparação entre a programação de pedido de proposta e a programação atual. Recomenda-se documentar duas semanas de antecedência e adicioná-las ao arquivo de mudanças.

Comunicações Diárias

Esta é outra questão importante a considerar durante o processo de documentação. Designe uma pessoa que possa armazenar e acompanhar os registos diários do projeto, notas de campo, condições climáticas, entrega, visitas oficiais do governo e conversas informais.

Esses arquivos devem ser mantidos e devem estar associados a datas e negociações afetadas pelo processo de decisão. Para cada questão, deve ser criado um registo separado e arquivado. Os registos de pedidos de mudança também devem ser mantidos e o registo deve incluir datas de vencimento, responsável, data de aprovação, especificações referenciadas e data de envio. Informações semelhantes devem ser registadas para desenhos, RFIs e especificações de projeto atualizadas.

Os carimbos de tempo normalmente são gravados na maioria dos documentos e os nomes legíveis são necessários para identificar quem recebeu ou assinou o documento, arquivo e / ou material. A hierarquia da equipe do projeto é importante para decidir se um gestor de projeto pode autorizar mudanças ou se precisa obter a aprovação de alguém superior na cadeia de comando.

Todos estes documentos devem ser mantidos e compartilhados com a equipe do projeto por meio de meios eletrônicos, desde que estejam disponíveis no futuro e sejam armazenados e documentados em ordem cronológica e por assunto.

Evidência Física

Com a mais recente tecnologia, recomenda-se gravar uma imagem aérea usando drone junto com fotos e outros vídeos, capturando recursos visuais sobre o status do projeto. Tire fotos em cada local antes do início do trabalho e continue o trabalho concluindo com uma revisão final após a conclusão do trabalho.

Essas fotos devem ser tiradas pelo menos uma vez por semana ou, de preferência, com mais frequência. Certifique-se que revê os documentos do contrato para se certificar de que seguiu o processo contratual para documentar as comunicações do projeto.

Vender o plano do projecto

Escrever o plano do projecto é só a primeira parte do trabalho. O próximo passo com importância igual é vender com sucesso o projecto aos stakeholders. Sem isto todos os seus esforços terão sido perdidos. 

Enquanto alguns gestores de projecto têm a sorte de já possuir o 'em frente' para o projecto, a maioria dos projectos têm de competir por financiamento e priorização dentro de um imensidade de outras prioridades de negócio, quer no âmbito de um programa ou portfólio de trabalho ou entre diversas funções de negócio. Isto faz com que o trabalho de vender o seu plano de projecto seja ainda mais difícil.

Normalmente o business case é a ferramenta principal para a venda do projecto, porque declara o PORQUÊ de um projecto ser realizado, listando os seus benefícios potenciais e os custos de conclusão do trabalho. Contudo, o plano do projecto é um componente chave da sua estratégia, porque nele foi possível demonstrar a credibilidade e viabilidade. Os decisores necessitam de ser convencidos de que estamos em condições de realizar o trabalho, que sabemos exactamente como queremos realizar o projecto, que o projecto é viável, que vale a pena fazê-lo e que será realizado de acordo com as expectativas.

Seja assim realista, não faça grandes afirmações ou crie expectativas demasiado ambiciosas que não possa substanciar. Isso voltará até a si no futuro para o atormentar! É muito melhor jogar pelo seguro e incluir declarações realistas e adequadamente conservadoras que estejamos seguros que podem ser realizadas. Não crie um garrote para enfiar o seu pescoço!
 

Trabalhar com os stakeholders

Trabalhe com os decisores e envolva-os o mais cedo possível no processo. É muito mais fácil fazer a viagem com estas pessoas do que vender-lhes «a frio» no fim. Consulte-os para definir os seus requisitos e expectativas, fale acerca dos seus pensamentos e concepções e faça com eles a revisão dos rascunhos iniciais. Assegure-se que trabalha sobre todas as preocupações levantadas antes de chegar à versão final, para que através dessa etapa eles estejam confortáveis com aquilo que está escrito no documento e, ainda mais importante, que não haja surpresas.

Trabalhar com cada um destes stakeholder pode custar muito tempo e trabalho, mas irá compensar o esforço, especialmente se ainda não se construiu uma relação com estas pessoas. Este processo permitir-lhes-á ver como trabalha e ajudá-lo-á a construir alianças importantes que podem ser cruciais conforme o projecto vá progredindo. Trazer as pessoas para o seu lado tornará a vida muito mais fácil quando as coisas se tornarem mais difíceis lá para a frente. Realizar esta abordagem deverá significar que a versão final do plano do projecto vaia entrar na fase de planeamento e receberá o apoio total para prosseguir para a próxima etapa do projecto.
 

Estabeleça a Baseline

Assim que o plano receba aprovação, assegure-se que estabelece uma baseline para o documento e garanta que existe um processo claro e transparente para gerir as alterações futuras.

Note: deve ter documentado isso na secção de «Controlos do Projecto» do seu plano.
É vital fazer visto, conforme o plano mantém a sua integridade como um documento aprovado de forma a poder ser referido como o plano base durante todo o projecto. Cada vez que uma alteração ao plano é feita, este é actualizado para uma nova versão e estabelecida uma nova baseline. Esta torna-se, então,a última versão a que nos referimos.
Logo que o seu plano é assinado e estabelecido o plano base está pronto a andar para a próxima fase do projecto – a Fase de Execução.
LQ

Razões para as falhas nos Planos de Projeto e como as evitar

Os planos de projeto em caminho crítico, quando a equipa não está a puxar para o mesmo lado, apresentam-se erróneos, apesar das melhores práticas usadas. A integridade do cronograma pode não ter nada a ver com a razão por que se tornou inútil ou sem sentido, ou como eu gosto de dizer, um gravador mais do que um preditor do caminho crítico e do progresso. Se o projeto é grande e tem múltiplos empreiteiros principais, o cronograma é bem mais suscetível de degradação.

"Um cronograma de CPM deixa de atingir o propósito pretendido, logo que se torna um gravador, em vez de um preditor.”

Muitas vezes, a falha de programação é previsível. Mesmo assim, pode parecer inevitável. No entanto, para cada obstáculo ao sucesso, há um caminho ou solução alternativa. Às vezes este é um remédio amargo e difícil de tragar. Cabe ao planeador fazer tudo o que puder para manter a integridade da programação do projeto. O que descrevemos abaixo destina-se a destacar os obstáculos mais desafiadores para planear o sucesso e oferecer soluções para estes.

Porque é que os cronogramas de caminho crítico na engenharia e construção são negligenciados, ignorados, incompreendidos e considerados inúteis?

Voto de desconfiança

Muitos profissionais da construção não ligam aos cronogramas de CPM (gestão de caminho crítico), talvez como resposta a experiências passadas, ou mais frequentemente, o voto de desconfiança é apenas destinado a mascarar a sua inexperiência que compromete a imagem profissional que pretendem passar.

Reconheça que planear em CPM é uma ciência que geralmente não é bem compreendida por não planeadores. Ignore a crítica desconstrutiva, ou tome-a como uma oportunidade para um momento de educação.

Faltas de reporting

Muitos empreiteiros pensam que podem passar com uma baseline e, subsequentemente, com um mínimo de atualizações de status possíveis. Talvez não sejam simplesmente obrigados pelo CM ou pelo proprietário.

Mantenha a procura de dados todos os meses e submeta uma atualização adequada, mesmo que não seja exigido. Impressionar sobre o empreiteiro a importância de manter atualizações mensais, especialmente no que se refere a reclamações. As reclamações  que têm lacunas de relatórios são mais prováveis de serem recusadas pelos revisores.

Erros de reporting e omissões

Muitos empreiteiros não mantêm registos precisos do progresso e são forçados a adivinhar nas datas atualizadas. Essa adivinhação pode voltar a assombrá-los se o proprietário tiver datas e dados diferentes. Outros simplesmente não seguem as instruções básicas do contrato. Finalmente, acreditam que apenas é necessária uma baseline de CPM.

Todos as questões acima referidas podem ser evitadas com a devida diligência. Impressione o cliente com a importância de manter o cronograma adequadamente, se por nenhum outro motivo, que seja para estar preparado em caso de reclamação.

Falta de liderança da gestão nível superior

Apesar dos poderosos MBAs, graus de engenharia e certificações exaltadas, muitos dirigentes de topo nunca vêem um gráfico GANTT adequado nos projetos sob sua administração. Eles podem considerar-se pessoas de "linha de fundo" - como se esta designação os dotasse com conhecimentos de CPM. Não.

O planeador será sempre mantido (pelo GC ou CM) o mais longe possível dos executivos do projeto, porque o seu conhecimento não dominado é um passivo. Na verdade, os resumos executivos de CPM não parecem atingir o público-alvo antes de estarem obsoletos. Estas circunstâncias estão fora do controle do planeador.

À medida que um projeto começa a perder tração, deve oferecer-se soluções e exigir o acesso a membros da equipe de nível superior para que possam ajudar a agilizar o processo ou facilitar os planos de recuperação ou mitigação ou mesmo para compreenderem uma reclamação.

Políticas

Muitas vezes, os GCs e CMs alteram indevidamente os relatórios de progresso para obterem vantagem ou ocultarem alguma outra realidade. Também manipularão e tentarão influenciar os relatórios ao seu gosto, ou adaptados ao gosto do destinatário. E no fim, eles simplesmente podem até não enviar os relatórios às partes interessadas.

Na primeira parte, é a integridade do planeador que está em questão quando se toma consciência de uma discrepância. Em suma,terá que fazer o que achou certo e deixar o responsável pelo relatório saber. Na medida em que não há nada que o planeador possa fazer para forçar o problema com as partes interessadas, ou mesmo induzir o responsável a publicar o cronograma, como deveria.

Incompreensão

Os membros da equipe da gestão da construção que ignoram o plano em CPM podem prejudicar o processo quando provam ser como estudantes sem vontade – demasiado orgulhosos para aprender. Eles também não possuem informações técnicas e analíticas. Por exemplo, à medida que um projeto vai por mau caminho, o cronograma pode ser referido como "inútil, obsoleto" ou pior, como se a integridade do cronograma dependesse do que ocorre hoje, na atualidade.

Novamente, deve educar o público quanto à diferença entre o progresso projetado e o progresso real e como a informação é disseminada numa atualização de plano.

Falta de um propósito comprometido

Muitos contratantes pensam que o cronograma é um requisito de projeto desnecessário. Como tal, eles planeiam apenas passar pelos movimentos, realizando o esforço mínimo e fazendo o planeador trabalhar mais.

Lembre o empreiteiro que manter o cronograma é como manter qualquer recurso que melhore em valor, na proporção de sua integridade, e que, no caso de uma reclamação de interrupção ser considerada, nada será melhor que um cronograma devidamente mantido.

Cedência do controlo do projeto

Os planeadores e estimadores de CPM são controladores de projetos. Ninguém mais, independentemente do seu título, o poderá ser. Apesar desse fato, os gestores de projetos tentam muitas vezes erroneamente micro-gerir o desenvolvimento do plano, em vez de o facilitar e aprofundar. Em outras palavras, eles tomam o "controlo" do "projeto": o que deve ser o trabalho do planeador. Os resultados são muitas vezes desastrosos.

Lembretes frequentes, mas gentis, geralmente induzem os gestores de projeto a serem mais amigáveis com o planeador e o plano. Deixe-os saber quando pisam a linha, ou quando pensam fora da caixa, e esforcem-se por os educar sobre as melhores práticas.

Rejeição

Muitos revisores de planos por parte do cliente deliciam-se em rejeitar ou não aprovar o agendamento enviado. Às vezes, como uma questão de posição legal: ou seja, eles acreditam que, ao rejeitar qualquer determinado cronograma, eles ganham alguma alavancagem contratual ao considerar o contratante não conforme.

Se a integridade do plano estiver intacta, e todos os requisitos das especificações cumpridos, simplesmente não é apropriado para um revisor rejeitar definitivamente um cronograma com base em aspetos técnicos mais comuns ou exigir um plano de recuperação, quando houver atrasos indemnizáveis.

Se este é o padrão, deve perceber que o revisor está a atrasar para evitar reclamação de interrupção. Pode até ser em seu detrimento para emitir um plano de recuperação ou plano de reclamação prévia – impedindo a realização. Na verdade, pode ser melhor interromper a publicação de atualizações - protegendo o cliente. Isso é certo: eu disse "parar de publicar atualizações": ou melhor, você emite-as, mas elas são retidas do revisor polémico até que um elemento imparcial possa ser escolhido para as rever.

Negligência voluntária

Um empreiteiro pode, desde o início, não ter intenção de manter o plano. Esta condição é aquela em que o planeador pouco pode fazer para mudar, além de ser persuasivo da melhor maneira que ele pensa que pode, sem ostracizar o cliente. Além disso, até talvez ninguém no nível executivo se oponha à ausência de atualizações e relatórios de cronograma, já que eles não os parecem entender ou rever em tempo útil.