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.

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.

Análise de Impacto As-Planned: com Primavera P6 combinado

O método de análise de impacto de atraso As-Planned é uma técnica que prevê ou prediz um efeito de atraso na data de conclusão de um projeto. Esse método de análise de atraso envolve a inserção ou adição de atividades que representam atrasos ou mudanças no cronograma de baseline para determinar o impacto dessas atividades de atraso. O uso do método de análise de cronograma As-Planned é geralmente limitado à quantificação de atrasos para pedidos contemporâneos de extensões de tempo.

A implementação da análise impacto de atraso As-Planned envolve a identificação de atrasos ou mudanças do projeto e, em seguida, inserir ou adicionar atividades, que representam esses atrasos ou mudanças, no cronograma de construção da baseline. A programação resultante demonstra o efeito dos atrasos ou mudanças na data de conclusão do projeto.

A realização da análise de atraso pode ocorrer numa situação combinada de múltiplos atrasos.

Se precisarmos ver um efeito combinado do evento de atraso 1 e do evento de atraso 2, teremos de criar um novo projeto e inserir esses eventos de atraso. Então, se precisarmos ver um efeito combinado do evento de atraso 1 e do evento de atraso 3, devemos criar um novo projeto e inserir esse evento de atraso. Este processo continua e podemos acabar com mais de 20 projetos.

Então, descobrimos que a Baseline precisa fazer um pequeno ajuste (por exemplo: adicionar mais 1 relacionamento), temos que editar os 20 projetos.

Isso vai ficar uma loucura.

Vamos ver como produzir um relatório de efeito combinado sem ter de criar todos estes projetos através do modelo de multi-projeto em Primaver4a P6.

O nosso projeto de Baseline é o da Figura 1:

Figura 1

Para 5 eventos de atraso vamos criar esses eventos em 5 projetos:

Figura 2

Pretendemos agora ver somente o efeito do Evento de Atraso 1, abrimos 2 projetos: a Baseline e o Delay Event 1.

Calculamos o projeto (F9) para vero efeito do Evento de Atraso 1. Contudo vamos de clicar na opção de Schedule “Ignore relationships to and from other projects”:

Figura 3

Faça F9 e pode ver o efeito do Evento de atraso 1 na Baseline:

Figura 4

A Extensão de Tempo (EOT) no exemplo é de 15 dias.

Agora queremos ver somente o efeito do Evento de Atraso 2, abrimos 2 projetos Baseline e Delay Event 2. Fazemos F9 para ver o efeito do Evento de Atraso 2.

Figura 5

A EOT é de 10 dias.

Agora se pretendermos ver os efeitos de ambos os Eventos de Atraso 1 e 2, abrimos os 3 projetos: Baseline, Delay Event 1 e Delay Event 2. Corremos F9 para ver o efeito de ambos os eventos.

Figura 6

A EOT seria de 25 dias.

Podemos fazer um processo semelhante como acima para ver o efeito combinado de qualquer evento de atraso ou todos os eventos de atraso:

Figura 7

Desvantagens da metodologia de análise de impacto de atraso As- Planned

Há uma série de metodologias de análise que serão usadas numa análise de atraso forense. O método de Impacto As-Planned foi amplamente utilizado nos primeiros dias do agendamento CPM, mas à medida que nos tornamos mais sofisticados no nosso agendamento, o As-Planned não é usado hoje como era, por estas razões:

O Impacto As-Planned não leva em consideração informações As-Built

O Impacto As-Planned ignora o fato de que o (s) caminho (s) crítico (s) podem mudar conforme uma programação é progredida

No entanto, na minha opinião, o método de Impacto As-Planned é simples de entender e fornece um bom ponto de partida para os planeadores que estão interessados em desenvolver seus conhecimentos de análise de atraso forense. Ele também fornece uma boa base para aprender outros métodos mais sofisticados, como Análise de Impacto de Tempo (TIA).

Erros comuns no Controlo do Projeto

TEMPO EFETIVO DE TRABALHO (Média de horas /turno que um trabalhador gasta diretamente a trabalhar em atividades na construção, manutenção).

Está estimado que um trabalhador gasta em média somente 3,5 horas a trabalhar efetivamente durante um turno de dez horas; este é um número assombroso. Quando faltam na indústria já tantos trabalhadores qualificados, não seria sensato tentar aumentar a performance dos trabalhadores? As poupanças que se conseguiriam em custos indiretos (deslocações, ferramentas, segurança, condições de vida, etc.) por si próprios poderiam poupar milhões em ultrapassagens de custos, sem mencionar um fator mais baixo de risco que se alcança por se empregarem menos pessoas, mas pessoas com as competências efetivas para desempenharem com segurança o trabalho.

Se pensa que este é só um problema sindical ou de atitude, volte a refletir. Esse tipo de consideração não nos levou a nenhum lugar no passado. Então onde se localiza o problema? Bem. Em muitos casos é uma falta de efetivo suporte da gestão. Se não acredita nisto, tente então: é uma falta de compreensão da gestão.

Temos de começar a olhar para as formas como a gestão pode usar ferramentas, formação, supervisão e planeamento para apoiar os trabalhadores a aumentarem o tempo de trabalho efetivo. Isto significa criar para os trabalhadores um ambiente de trabalho seguro tão eficiente como possível e fornecer as ferramentas, direções, materiais, equipamento e apoio tão efetivo quanto possível para permitir aos trabalhadores realizarem as atividades atribuídas.

Demasiadas vezes a um trabalhador não são fornecidos em tempo, autorizações de trabalho, reuniões de definição de trabalho seguro, ferramentas, materiais e equipamento ou instruções suficientes para executar o trabalho. Perdem tempo à espera, à procura de ferramentas, de materiais, à espera de recursos de suporte e ficando frustrados com a gestão do projeto. Adicione as pausas de café, almoços, reuniões de segurança, limpezas e acabámos de reduzir a quantidade de trabalho que um trabalhador gasta nas ferramentas em mais de 60 por cento.

Mas então qual é a solução?

Passei centenas de horas com equipas de gestão, e outros recursos treinando, educando e apoiando para o desenvolvimento de estratégias para a definição do trabalho, planeamento do trabalho, agendamento e supervisão da execução. Descobri que na maioria dos casos a vontade para realizar trabalho de qualidade é prevalente em todas as categorias. Eles estão geralmente frustrados por não conseguirem alcançar as metas de performance para os seus clientes. O que falta é uma relação construída sobre claras expectativas e confiança. Os contratos são muitas vezes deficientes na definição do âmbito e dos indicadores de performance.

Uma companhia de topo terá de fazer isto através do estabelecimento de um processo formal para gestão de projeto e controlo suportado em melhores práticas na forma de políticas, procedimentos e orientações e ferramentas de gestão. Toda a gente desde os recursos a contrato até ao pessoal de gestão interno é educado no seu propósito e utilização.

A liderança e prestação de contas decorre de uma Equipa de Gestão que é estabelecida nas etapas mais precoces do projeto que assiste à definição do âmbito, à determinação dos riscos e ao estabelecimento das metas chave de performance, para a segurança, qualidade, performance do trabalho, custo e duração do plano. Através dum planeamento efetivo, contratação, procurement e agendamento a Equipa poderá determinar os números corretos de recursos diretos e indiretos exigidos para executar o trabalho.

Ao estabelecer um grupo de controlo de projeto (em oposição a um grupo de monitorização – o que é muitas vezes o caso), uma companhia pode dirigir o plano do projeto dia a dia, medir a performance, dados de tendência e realizar os ajustamentos necessários para controlar o resultado. Istro é denominado uma gestão de agendamento dinâmico.

Demasiadas vezes os projetos saem dos carris devido à falta de controlos efetivos de projeto. Vou listar alguns dos principais erros que conduzem sempre à perda de tempo efetivo de trabalho.

As companhias NÃO…

• Usam um processo formal de gestão da execução do projeto que permita à gestão de topo verificar a conclusão de milestones em etapas pré-determinadas antes das entregas. Isto é muitas vezes denominado um agendamento de Milestones ou um Processo de etapas.
• Estabelecem uma Equipa de Gestão que integre a Gestão Sénior (Liderança), um Gestor de Projeto quie reporte à Gestão Sénior e uma Equipa Central de Gestores que represente cada um dos Departamentos participantes, i.e., Manutenção, Operações, Contratação / Comercial, Administração, QA/QC, Materiais, Procurement, Ambiente, Engenharia, Logística, etc.
• Utilizam uma ferramenta formal de análise de benefício de risco / custo.
• Desenvolvem um orçamento preliminar baseado no âmbito do trabalho determinado pela ferramenta formal de análise de benefício de risco / custo. O orçamento preliminar deve ser desenvolvido com estimativas das horas diretas de Tempo Efetivo de Trabalho, suportado pelas estimativas de recursos indiretos com uso de dados standard da indústria. Usualmente o suporte indireto é 115% das horas de tempo efetivo direto.
• Estabelecem um processo formalizado de Gestão da Mudança para limitar o crescimento do âmbito e gerir quaisquer mudanças que afetem o orçamento.
• Estabelecem metas chave de performance realistas para segurança, qualidade, performance do trabalho, custo e duração do plano. Com foco na segurança e na performance do trabalho irá permitir em última análise ter sucesso no alcançar das metas de performance de qualidade, custo e agendamento.
• Criam um processo formal de gestão que permita a identificação precoce do trabalho seguido através de contratação e procurement.
• Envolvem, como muito importante, a produção e a supervisão do trabalho em obra no processo de planeamento e agendamento cedo durante a fase de planeamento. É também recomendado o uso de supervisão independente da execução em obra. Relembre que planeamento, agendamento e coordenação não são posições, são funções. Cada função necessita de ser atribuída aos recursos adequados, ou equipas, para gerir.
• Estabelecem controlos de projeto efetivos e agendam dinamicamente as atividades planeadas com base me intervalos de status regulares, i.e. dia a dia ou semanalmente nos projetos de construção.

Transformar digitalmente as empresas de Construção

A E & C (Engenharia e Construção) está ainda atrasada apesar da enorme oportunidade internacional de projetos em carteira. As empresas nacionais olham para o mercado mundial de forma aberta e temos exemplos de grande sucesso. Entretanto, vários relatórios internacionais afirmam que a E & C está entre as indústrias menos digitalizadas, ficando no segundo lugar a contar do último entre os maiores setores económicos no investimento em tecnologia. Como resultado, a produtividade do trabalho continua a arrastar-se na traseira do resto da economia mundial. Conclusão: se a indústria da construção quiser capitalizar a oportunidade deve juntar-se rapidamente à revolução digital ou arriscar perder a locomotiva da tecnologia completamente.

Quais são os desafios chave e soluções potenciais que a indústria enfrenta:

Soluções pontuais descoordenadas

Praticamente todas as grandes organizações de E & C alcançaram algum nível de digitalização, mas muitas delas dependem de soluções funcionais separadas que não comunicam entre si. Sem uma plataforma digital integrada, os utilizadores compartilham ficheiros e informação dispersos por e-mail ou serviços de armazenamento baseados na nuvem, resultando em documentos perdidos, retrabalho, falta de responsabilidade e atrasos na produtividade.

A solução: utilize as APIs abertas para conexões contínuas para software e serviços de terceiras partes, conectando os dados das aplicações. Invista em armazenamento de dados (ou seja, "um lago de dados") que permita que a informação seja partilhada e analisada, levando potencialmente a novos conhecimentos.

Falta de standardização

As empresas globais de construção utilizam geralmente uma ampla gama de processos e procedimentos para executar o mesmo trabalho. A falta de padronização em projetos globais em rápida expansão pode tornar-se uma grande dor de cabeça para parceiros e subcontratados, incluindo: ineficiências de projetos, erros, tempo de inatividade e potenciais riscos de segurança.

A solução: simplifique os processos existentes, eliminando sistemas desnecessários ou ineficientes. A adoção de uma plataforma de colaboração de projetos que abraça a uniformidade levará a maior eficiência em parceiros e projetos.

Falta de talento tecnológico

Há uma falta generalizada de conhecimento tecnológico na E & C global. Mas nem todos os empregados precisam ser um técnico. Alguns indivíduos digitalmente experientes são certamente necessários, mas a maioria da força de trabalho precisa apenas do conhecimento básico das plataformas-chave. Assim como um motorista de pesados de longa distância para dirigir um veículo de 18 rodas não precisa saber como desmontar e reconstruir um motor, a maioria dos empregados não precisa saber como escrever código para usar o software.

A solução: formações práticas e programas de certificação podem ajudar a atualizar os empregados num período de tempo relativamente curto. Analisar criteriosamente o nível de conhecimento técnico dos funcionários também pode simplificar o recrutamento e a contratação.

Resistência à adoção de software

A introdução de novas tecnologias para a força de trabalho existente pode causar apreensão, especialmente entre a gestão sénior. Se a solução cria uma curva de aprendizagem íngreme ou não entrega imediatamente os objetivos prometidos, os empregados ignorarão ou abandonarão completamente a tecnologia.

A solução: as organizações precisam estar cientes de que a resistência à mudança está na natureza humana. Os líderes devem criar programas de comunicação, formação e treino e gestão de mudança para incentivar a adoção de software.

O que é o ROI?

Mudanças dramáticas em tecnologia e processos são geralmente assustadoras e desafiadoras - especialmente se o retorno do investimento não estiver claro. Por exemplo, como se pode medir melhorias qualitativas em processos e metodologias? Métricas fáceis e / ou nenhum "executivo" designado " campeão tecnólogo " podem resultar em que a gestão de topo evite completamente o novo investimento tecnológico.

A solução: os líderes da organização devem estabelecer uma linha de base para as operações atuais para monitorizar com precisão as melhorias ao longo do tempo e promover os seus sucessos ao longo desta transformação digital.

Resultados mais importantes

Alcançar a transformação digital completa é mais do que apenas processos padronizados e produtividade melhorada. As orientações do governo, como o requisito no Reino Unido de implementar sistemas de gestão de informações de construção (BIM) para projetos de infraestruturas públicas, forçam grandes companhias de E & Cs a adotar tecnologia digital ou a perder em projetos vários bilhões de dólares.

A implantação de uma plataforma de software de colaboração, em última análise, proporciona informações sobre as organizações numa variedade de projetos, permitindo que elas tomem decisões mais estratégicas e abordem pequenos problemas antes de se transformarem em grandes obstáculos.

Aderir à revolução digital assegurará que o setor de E & C não seja deixado para trás.