Identificar o que pode atingir o projeto

Uma séria abordagem do Risco continua a ser a maior lacuna nos projetos no nosso país.A razão para isso entronca no deficiente conhecimento mas também na dificuldade de enfrentar a incerteza de forma prática.

O primeiro passo no processo de gestão de risco é descobrir o que enfrentamos. Que tipos de coisas ameaçam a capacidade de fornecer o que se prometeu? Tudo começa com a incerteza de não saber exatamente como as coisas vão acabar. Esta é apenas outra maneira de dizer que muitos aspetos dos projetos são imprevisíveis, apesar dos esforços para realizá-los. Eis algumas das áreas mais comuns de incerteza.

Área	Descrição
Âmbito	Extensão estimada do trabalho, capacidade de definir com clareza o trabalho, erros de desenho e omissões, mudança de âmbito dirigida pelo cliente
Tempo	Duração estimada do projeto, duração estimada de atividades, tempo para o mercado, data de lançamento, escala de revisões de gestão e aprovações
Custo	Custos estimados do projeto, custos de produção do procurement, custos de manutenção, Inflação, variações cambiais, limitações de orçamento
Tecnologia	Expetativas do cliente, probabilidade de sucesso, capacidade de escalação, sucesso do design, capacidade de produção
Recursos	Quantidade, qualidade, disponibilidade, competências adequadas, definição de funções e responsabilidades
Organizacional	Prioridades e conhecimentos do cliente, coordenação entre departamentos
Adaptação	Expetativas dos utilizadores, volume de vendas, demografia, qualidade, geografia, economia
Fatores externos	Ações e reações externas, regulação

Tabela 1 - Áreas típicas de alta incerteza

A partir destas fontes de incerteza, surgem questões. Estas são o que precisa descobrir, problemas potenciais específicos, quantos você puder imaginar. Mas como vai identificar problemas? Não há uma fórmula mágica para identificar possíveis ameaças ao seu projeto. Isso exigirá conhecimento específico do projeto, capacidade intelectual significativa e capacidade de especular. Hummm ... isso soa como uma excelente oportunidade para um evento de team-building.

Os melhores eventos de teambuilding são aqueles em que os membros da equipa expandem os conhecimentos uns dos outros e do projeto ao mesmo tempo. Identificar possíveis problemas como equipa é uma maneira ideal de conseguir isso. Caracterizo o efeito de eventos como este como construção da inteligência coletiva da equipa. Especificamente, a abordagem começa pela reunião de toda a equipe. Recomendo reservar de duas a quatro horas, dependendo do tamanho e da complexidade do projeto. Reúna cada peça Reúna toda a documentação que você puder e peça aos outros que façam o mesmo.

Documentos em background típicos podem incluir o Documento de Requisitos, o Documento de Definição do Projeto e o business case. De valor mais imediato, serão os documentos de planeamento do projeto, como a WBS, o cronograma de controle do projeto e a Matriz de Atribuição de Responsabilidades. Finalmente, estruture qualquer documentação de suporte relevante, como base de planos de estimativas, suposições de planeamento e o diagrama de rede usado para o desenvolvimento do cronograma.

O ponto central de tudo isso é que pretendemos que o maior número possível de documentos ajude e estimule o pensamento sobre possíveis problemas. Uma lista de verificação também pode ser bastante útil para estimular a especulação. Considere usar uma lista de verificação similar a esta quando realizar a reunião com a equipa.

Âmbito do Projeto _ Cliente adiciona âmbito ou funcionalidades _ Trabalho não pode ser definido com rigor _ Âmbito está subestimado _ Objetivos do projeto mudam	Instalações e equipamento _Indisponibilidade _Fraca confiança _Incompatibilidade com existente _Limitações proprietárias _Fraca flexibilidade _Má localização e espaço	Pessoal _Férias/Doenças _Família e outros _Interesses em conflito _Distrações externas _Questões éticas _Questões morais
Cronograma do Projeto _ duração subestimada do projeto _ Data de fim altera-se durante o projeto _ Data de fim irrealista _ Atraso nas aprovações _ Revisões da gestão atrasam projeto	Recursos _Mudança nos elementos da equipa _Financiamento _Custos/despesas incertos _Indisponibilidades _Prioridades desalinhadas	Interpessoais _Performance/ produtividade _Conflitos interpessoais _ Desenvolvimento _Má motivação e atitudes _Competências desajustadas
Materiais _ Fonte e disponibilidade _ Integração pobre com o existente _Deficiente confiança do fornecedor _ Confiabilidade do material _Qualidade fora do standard _Alto preço	Organizacional _Difusas funções e responsabilidades _Pobre delegação _Relações más entre unidades _Falta de coordenação _Conflitos entre unidades _Pobres comunicações _Limitações de política	Influências Externas _Meteorologia e desastres _Regulação e governo _Higiene e Segurança _Barreiras culturais _Tensões políticas _Mudanças económicas _Posição política desfavorável

Tabela 2 - Lista de verificação de questões

Relacione o máximo de problemas possíveis, com o uso técnicas de brainstorming. Embora não queira sufocar a criatividade, tente manter a lista com um tamanho razoável (talvez de 30 a 50, dependendo do tamanho e da complexidade do projeto).

Ao listar possíveis problemas que ameaçam o projeto, não perca de vista o conceito de incerteza. Lembre-se de que a falta de informação, conhecimento e compreensão é realmente o inimigo. Em outras palavras, pense nas maiores “ameaças” como aquelas que têm o maior potencial para o desviar o mais longe possível - numa direção desfavorável.

Como sabemos que os requisitos da solução estão concluídos?

Até onde é que podemos levar a Elicitação (escolha de requisitos) num projecto? Parece-me que, de forma definitiva, ninguém sabe a resposta. Será muito dispendioso capturar todos os requisitos, assunções, regras, relações e ligações escondidas associados à solução em construção. Então temos de ter uma forma de saber quando fizemos o que deve ser feito.

Conforme se elícita, analisa e documenta requisitos, devemos estar atentos à informação que a reunir e determinar o tempo que passa entre a descoberta de novos requisitos ou mudanças significativas aos requisitos existentes. Quando a duração excede um determinado limiar, então termine as actividades de recolha de requisitos – este é o processo de preparação de pipocas no microondas, ou a Via das Pipocas.


Este limiar pode, ainda, ser identificado com base num princípio de confirmação: Se, durante o processo de descoberta de requisitos se chega a um momento em que se continua a acumular informação mas esta não se traduz em novos ou alterados requisitos, então sabemos que devemos ter chegado ao fim.

Esta métrica é a solução melhor para situações em que no analista de negócio tem como propósito elicitar e documentar os requisitos de negócio detalhados quando o projecto possui “um charter definido com razoabilidade e objectivos de negócios claros”. Mas, é ainda útil, durante todo o ciclo de vida do projecto, quando se tenta definir âmbito e estabelecer requisitos de negócio para o projecto.

O desenvolvimento de requisitos é um processo iterativo, que se inicia a um alto nível de compreensão das capacidades requeridas, estas são então decompostas em componentes mais pequenos, que são por sua vez mais fáceis de tratar e desta forma determinar até que ponto estamos «terminados» em cada uma delas. Alguns exemplos do que pode ser tratado como componente independente, incluem:

• Definição do Âmbito – quais as capacidades que serão e que não serão incluídas no âmbito do projecto.
• Regras de Negócio – Regras referente à tomada de decisões operacionais que devem ser tomadas em atenção na solução.
• Modelos de factos – Modelos que representam conexões lógicas (“factos”) entre os conceitos centrais de uma solução e servem como representação do desenvolvimento subsequente de modelos de dados.
• Requisitos funcionais – As capacidades da solução – funções que a solução irá realizar ou permitir que os utilizadores o façam com o software.
• Requisitos não funcionais – Os critérios utilizados para ajuizar a qualidade da solução aparte os seus comportamentos específicos (requisitos de resposta em tempo, capacidade, confiança, usabilidade, etc.)
• Interfaces externos – Os interfaces para outros sistemas e entidades externas dentro do âmbito do projecto.

Esta não é uma sugestão de ordenação, antes a compreensão de que quando se trabalha em requisitos se realizam muitas actividades em simultâneo. Esta regra de economia permitir-nos-á saber com mais confiança qual a linha que estabelece que o trabalho está feito. Os riscos de parar cedo demais e falhar requisitos críticos, ou gastar demasiado tempo num dado conjunto de requisitos (gastando assim tempo valioso) são muito reduzidos quando damos atenção ao «silêncio dos requisitos» (o ponto em que mais informação não está a ajudar a identificar ou refinar requisitos).

Conforme o processo de requisitos se inicia, vai ficando cada vez mais confiante na forma como o problema foi definido quando vai verificando que os stakeholders das diferentes categorias e perfis concordam acerca do que é o problema e como a solução de sucesso irá ser. Passados uns dias e enquanto se vai adicionando e negociando detalhes dos requisitos, pode determinar-se que não houve mudanças no âmbito. Tal permite, por exemplo, declarar que a parte do âmbito do processo de gestão de requisitos está concluída, o que permitirá focar a atenção em outras secções ainda não investigadas.

Saber quando estão concluídos os requisitos para um projecto não é sempre fácil, mas encolher a dimensão dos seus objectivos é uma grande forma de reduzir a luta que sentimos. Ao estabelecer objectivos de menor dimensão e aplicando uma regra de «silêncio dos requisitos» para cada um destes objectivos separadamente, incrementará a capacidade de visão acerca da distância para a meta que se pretende atingir.
Luis Quintino

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.

A delegação em Projeto

O sucesso na delegação de actividades é essencial para o êxito na gestão de projeto. Contudo, muitas das pessoas envolvidas como líderes em gestão de projeto têm medo da delegação. Eles receiam que, se delegarem, o trabalho este 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 projetos depende simplesmente da delegação por força da lei da divisão do trabalho: uma pessoa ou equipa focada em uma ou duas atividades específicas é mais eficiente e produtiva que uma pessoa que tenta realizar simultaneamente uma multitude de atividades. 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 projeto melhor. No fundo que o melhor gestor é o que gere menos.


O sucesso da gestão de projeto 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 direçã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 estar 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 projeto ou das suas atividades. 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 projeto 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 atividades. Se é este o caso, deve assegurar-se de delegar numa pessoa como o contacto directo e o gestor do projeto. 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 projeto 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 projeto. 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 objetivo do projeto. 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 projeto – É 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 atividade – 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 atividade – 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 projeto. 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 projeto 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 projeto alcança o que todos desejam – o sucesso.

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.

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

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.

Deite fora as folhas de cálculo: Ultrapasse a resistência à mudança!

Eu trabalhei como consultor do setor da engenharia e construção por muitos anos.Observei um tema comum: sempre que apresento uma nova solução de software moderna, particularmente uma ferramenta que apresenta uma abordagem nova e disruptiva para um problema de negócio, enfrento muitas vezes algum grau de resistência de alguns dos assistentes.

Os céticos costumam afirmar que podem usar uma folha de cálculo mais rapidamente do que aprender e implementar uma nova aplicação de software. Até pode ser verdade em alguns casos, mas não está certo.

Por exemplo, durante uma apresentação em que participei, todos concordaram unanimemente que o sistema existente e os processos de negócio eram ineficientes, caros, difíceis de aprender e com pesados custos administrativos. Dois indivíduos que discordaram dessa avaliação foram um administrador de TI e um programador interno - profissionais inteligentes e competentes.

A minha teoria: a possibilidade de mudança é a maior preocupação para muitos retardatários digitais mais do que o risco de falha na entrega do projeto - se a mudança proposta impacta a sua segurança no emprego, aumenta ou diminuiu as horas de trabalho ou introduz algum outro inconveniente pessoal.

O que me leva à pergunta: por que há tanta oposição à melhoria dos processos de negócios com a transformação digital?

Mitigar o risco com sucesso

Considere o risco por um momento. Muitos motociclistas que andam dezenas de milhares de quilômetros sem acidentes podem ter permanecido intactos pelas seguintes razões: 1) conduzem de forma conservadora e segura 2) vestem roupas altamente visíveis com refletores à noite 3) veem as consequências de um acidente como maior que o custo ou inconveniência de preparação ou formação. Esses motociclistas estão a mitigar com sucesso o risco - semelhante àqueles que adotam a transformação digital na indústria de engenharia e construção (E & C).

A luz no fim do túnel na indústria de E & C

A mensagem "a luz no fim do túnel" foi repetida durante anos e, francamente, é uma referência desatualizada de projeto de construção. Os túneis bem-sucedidos e bem iluminados de hoje são construídos como um ativo digital muito antes que a ponta da broca toque qualquer rocha. A maioria das organizações concorda com a importância de manter uma reputação de "dentro do prazo, dentro do orçamento" no atual mercado de construção competitivo. A colaboração eficaz e a comunicação eficiente entre centenas de organizações que participam das fases de projeto, licitação e construção de projetos de infraestrutura são a verdadeira luz no fim do túnel – do início ao fim - tornando o risco visível.

A transformação digital expõe o risco, incluindo:

• Excessivos RFIs criados pelas mesmas pessoas no início de um projeto ou um processo de aprovação que demora mais do que o esperado.
• Falta de fluxo de informações - particularmente durante a fase de design.
• Demasiadas revisões de documentos sem acompanhamento de revisões efetivas ou de distribuição.
• Processos atrasados, incompletos ou finalizados.

O valor de compreender como e por que estes riscos ocorrem - e mitigar precocemente estas instabilidades - supera em muito o custo ou a inconveniência da capacidade de preparação. Isso coloca, de fato, a luz no começo do túnel, onde é realmente necessária. As folhas de cálculo não podem fazer isso de maneira oportuna e eficaz. A transformação digital na gestão da construção é exatamente o método de realização para obter isso.