Mostrar mensagens com a etiqueta Gestão. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Gestão. Mostrar todas as mensagens

quinta-feira, outubro 17, 2019

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.








quinta-feira, outubro 10, 2019

Principais Categorias de Riscos

Abaixo descrevemos algumas das áreas que devem ser averiguadas (ou pelo menos visitadas) para verificar se existem alguns riscos escondidos ao longo de todo o projecto. Pode funcionar como um embrião para a criação de um Registo de Riscos para utilizar em projectos. Então aqui vai:

Riscos relativos ao Âmbito – Deslizar potencial do âmbito porque os requisitos do projecto não estão definidos com clareza. Foi bem definido o critério de performance? Estão definidas todas as condições limite? Onde começa e acaba o trabalho? Foram definidas as responsabilidades de todas as partes nas diferentes fases do projecto? Foram definidos os procedimentos de gestão da mudança do âmbito? 
IMG00012-20101031-1140
Riscos relacionados com o Plano e o Esforço
– O deslizar do âmbito é um risco de grande dimensão para o plano e o custo mas estimativas de qualidade pobres são também um factor significativo. A falta de experiência anterior. Conhecimento experimentado da área de actividade, falta de adequadas revisões e verificações são as causas para estimativas inexactas. Ser pessimista faz-nos ganhar pontos e devemos quase ser paranóicos quando se trata da estimação do projecto. O optimismo mata, muitas vezes!

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

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


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


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


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


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


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


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


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


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


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

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


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


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

segunda-feira, abril 09, 2018

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





quarta-feira, março 28, 2018

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  pessoasequipa

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.

quinta-feira, março 08, 2018

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.

quarta-feira, janeiro 24, 2018

Modernize o Controlo do Projeto, não seja atropelado por um autocarro!

O setor da construção está a transitar rapidamente do legado da velha escola e das ferramentas ad hoc para soluções modernas integradas e voltadas para o futuro. Tal não é ainda aparente no nosso país, mas os sinais começam a sentir-se, nomeadamente em projetos de maior dimensão. Com esta mudança de indústria em mente, o que preferiria: saber a matrícula do autocarro que o vai atropelar ou ser avisado de que um autocarro vai na sua direção?
Por outras palavras, preferiria ficar com o status quo, a gastar recursos valiosos em pesquisas e acompanhamento da equipe, ou preferiria usar a tecnologia moderna para fornecer informações atualizadas e prospetivas para que a equipe possa planear, analisar e executar de forma eficaz?
Os principais projetos e organizações de construção estão a escolher o último - e irão colher os benefícios de informações oportunas e impactantes. Aqueles que não fazem este movimento para a tecnologia atualizada simplesmente serão deixados para trás.
Este é um momento de um processo que se estende por anos e centenas ou milhares de companhias. Implica mais maturidade nas forças de trabalho e equipas, mais formação e, claro, tecnologia.

"Falhar em planear é planear para falhar"

Esta frase é adequada para aqueles que optam por não usar tecnologia moderna para gerir processos e entregar projetos. Mesmo nos últimos cinco anos, a indústria da construção continuou a amadurecer. A adoção de novas tecnologias já não é arriscada; não adotar é.
O tamanho e a complexidade dos projetos estão a crescer, impulsionados tanto pela procura como pela tecnologia de engenharia. Novos modelos de contratos estão a ser implementados para responder a essa complexidade, mas trazem outros desafios, incluindo maior necessidade de colaboração entre organizações, requisitos de relatórios e risco de projeto distribuído. Os líderes de ponta da indústria estão a mudar do relatório de custos para a gestão de custos, afastando-se da maioria das companhias e para reforçarem a sua posição como líderes.

Regras de ouro para modernizar os controlos de projeto

É essencial capacitar os profissionais de projeto para enfrentarem o trabalho de alto valor. Os projetos serão mais bem-sucedidos quando as equipas planeiam antecipadamente, ao invés de gastar o tempo à procura de informações de acompanhamento, que são ironicamente desatualizadas na conclusão.

Urge seguir 3 regras de transformação das organizações para melhorar o controlo dos projetos.
  • Regra # 1: Automatizar o máximo possível.
  • Regra # 2: Usar sistemas configuráveis para gerir os processos e informações durante todo o ciclo de vida do projeto.
  • Regra # 3: Implementar soluções abertas que se liguem a outros sistemas para obter informações abrangentes do projeto.


sexta-feira, janeiro 12, 2018

O que realmente é Controlo do Projeto

O termo controlo tem vários significados. Pessoas novas na gestão de projeto ou com experiência limitada no planeamento ficam preocupados pelo uso do termo "controlo", porque equivocadamente o equiparam-no com o conceito de autoridade. No mundo da gestão de projetos, o controlo tem pouco a ver com dizer às pessoas o que fazer, ditar suas ações ou pensamentos, ou tentar forçá-los a comportar-se de determinadas maneiras - todas as quais são interpretações comuns de controlo.
Na gestão de projetos, o termo "controlo" é muito mais análogo à direção de um navio. Trata-se de fazer ajustes continuamente no rumo com um dos principais objetivos em mente, trazer o navio para o porto seguro, como prometido no início da viagem. E a viagem bem-sucedida do projeto inclui a identificação de um destino específico, elaborando cuidadosamente uma rota para lá chegar, avaliando a localização ao longo da viagem e mantendo um olhar atento sobre o que está por vir.

O objetivo do controlo do projeto

Gestores de projeto novatos (e alguns experimentados!) cometem, muitas vezes, o mesmo erro ao tentar manter o controlo dos projetos. Eles estão embrulhados no aqui e agora  a medição e avaliação da situação imediata – com a exclusão de tudo o resto. Eles calculam a posição atual e até onde estão fora do curso. Isso é o que eles relatam para a gestão e prometem reparar. Todo o foco consiste em permanecer na linha que desenharam desde o início até o final do projeto. Infelizmente, controlar o destino do projeto não é tão simples.

Como vemos, a avaliação de onde se está em termos de onde você deve estar faz, certamente, parte do controlo geral e "voltar a ficar na rota" é quase sempre uma estratégia sólida. Mas a principal missão é entregar o que prometeu, então deve pensar em "manter o controlo" em termos de minimizar a distância entre onde termina e onde disse que acabaria.

Isso significa que o controle geral do projeto exige um olho no futuro.

Manter o controlo adequado exige realmente que você considere três parâmetros: (a) onde está, comparado com o local onde deveria estar; (b) o que está por vir que pode afetá-lo; e (c) onde vai acabar, em comparação com onde disse que acabaria.

De forma mais técnica o controlo do projeto consiste no seguinte processo contínuo:
  1. Monitoração contínua do progresso do trabalho
  2. Comparando-o com o cronograma e orçamento da baseline (o que era suposto ser)
  3. Encontrar desvios, determinar onde e quanto, e analisá-los para descobrir as causas
  4. Tomar medidas corretivas sempre que for necessário para repor o projeto no prazo e dentro do orçamento.


segunda-feira, janeiro 08, 2018

Planeamento desde o início

O planeamento é tudo sobre oportunidade. Temos muitas opções durante a etapa de planeamento. Algumas opções são mais atraentes ou viáveis, e espero que a opção menos dispendiosa gere o melhor resultado. Mas certamente pode ser mais complicado do que isso. 
No início, na etapa de proposta, as opções colocadas têm a ver comas opções técnicas, a abordagem de execução e o melhor rendimento possível para a realização dos trabalhos propostos. São opções complexas e difíceis de concretizar com sucesso. Então porque é que na proposta não é oferecido um papel importante ao planeamento e à discussão sobre as oportunidades de sucesso ótimo da realização.
Na maioria dos casos e lamentavelmente, encontramos propostas de plano iniciais, apresentadas na licitação, que vão somente trazer preocupações e dificuldades durante a execução, no caso de adjudicação da proposta.

No caderno de encargos inicial os clientes incluem, muitas vezes, opções que visam testar a forma como planeamos a execução e dessa forma obtém uma apreciação à ponderação das opções por parte dos contratantes. O Departamento de Transportes da Califórnia (Caltrans), por exemplo, utiliza uma abordagem "A + B" em projetos maiores: cada licitante deve especificar uma duração do contrato e um preço. Ambos os números são considerados na adjudicação de projetos. A experiência de Caltrans é que as ofertas de A + B resultam em preços mais baixos e menos atrasos no uso final dos projetos. Estes processos começam a ser integrados na regulamentação de concurso ou nas instruções dos cadernos de encargos

Quanto mais aguardamos para tomar decisões, menos opções permanecerão viáveis. Esta é uma das atitudes tomadas por contratantes em resistência a tomar decisões sobre os projetos em períodos iniciais do contrato, designadamente sobre os seus planos, as abordagens de trabalho, ou os rendimentos de execução. Algumas vezes esta linha de orientação entra em confronto com o cliente. Quando a decisão for inevitável as opções são quase sempre duais.
Durante a execução do projeto encontramos muitos projetos em que o plano só é usado por insistência do cliente e o seu rigor técnico e qualidade deixam muito a desejar. Devemos lembrar-nos que os projetos terminam a tempo porque monitorizamos o progresso de forma regular e implementamos estratégias de mitigação sempre que ocorre deslizamento.  Para obtermos este resultado temos de valorizar e utilizar adequadamente um plano de projeto.

Luís Quintino 

quinta-feira, dezembro 21, 2017

Porque é que o Email é tão ineficiente em Projeto

Apesar da forte constatação de que o e-mail é uma ferramenta ineficiente, continua a ser um dos métodos de comunicação mais frequentes na gestão de projetos complexos. Precisamos entender o papel sistemático da comunicação em co9nduzir um projeto para o estado de sucesso desejado. Muitos gestores de projeto cometem o erro de presumir que, se uma mensagem foi enviada, ela será efetivamente recebida. Infelizmente, nem sempre é esse o caso e "e-mail enviado = mensagem recebida" não é certamente uma das regras de comunicação que devem ser tomadas como garantidas.

A importância da comunicação na gestão de projeto

É óbvio que a comunicação é um dos fatores mais enfatizados e que determinam o sucesso ou o fracasso de qualquer projeto. É bem entendido que a comunicação eficaz pode ser uma tarefa desafiante, especialmente quando um projeto incorpora pessoas com diferentes habilidades, níveis de autoridade, responsabilidades, experiência e origens.

A comunicação é ainda mais desafiante quando as pessoas envolvidas trabalham em diferentes empresas sob diretrizes de trabalho separadas. Os especialistas definem a comunicação efetiva como uma em que a mensagem transmitida transfere a mesma importância e significado para o recetor que o remetente tinha em mente, incentivando o recetor a tomar a ação desejada.


Questões com a utilização do email como o Canal Primário para Comunicação

Muitas vezes, cometemos o erro de usar o email como principal canal de comunicação, o que dá origem a mal-entendidos. Ao usar o e-mail como um canal de comunicação primário, assumimos muitas coisas, tais como:
  • A mensagem é perfeitamente compreendida pelo seu recetor
  • O recetor leu a mensagem dentro do período de tempo esperado
  • O envio de e-mail é suficiente para alertar o recetor e para gerar a resposta ou a ação desejada
  • O recetor aceita a tarefa e irá entregá-la dentro do prazo esperado e os custos.

Basta que apenas uma dessas hipóteses se revele falsa para criar problemas para todo o projeto. Um responsável que não compreende completamente a tarefa ou um membro da equipe incapaz de reagir ao tópico do e-mail no tempo pode criar um atraso ou mesmo uma crise, sem que isso seja culpa dele. O uso excessivo de e-mails em vez de métodos de comunicação direta, como telefone, conversa, videoconferência, face a face, etc., leva a problemas críticos de comunicação.
Muitas coisas podem dar errado, incluindo a conclusão do trabalho, o período de tempo remanescente, os atrasos na atribuição de tarefas, os conflitos internos devido a um mal-entendido das tarefas atribuídas e assim por diante.
Então, porque é que as pessoas ainda pensam no e-mail como muito à mão, e como a comunicação por e-mail pode criar negligências na gestão de projetos?

Mas como é que o email ainda é a escolha mais conveniente?

  • O e-mail é quase gratuito em comparação com outros canais de comunicação, como videoconferência, telefone ou uma viagem
  • O e-mail é fácil de usar e a maioria da força de trabalho está familiarizada com a sua funcionalidade.
  • Os e-mails são rápidos e fáceis de escrever e de usar; às vezes, é mais conveniente comunicar com várias pessoas ao mesmo tempo através de e-mails, em vez de persegui-los para ter uma conversa cara a cara.
  • O e-mail pode ser usado para evitar conversas individuais em instâncias em que o remetente quer falar sobre algo negativo ou desagradável. É uma boa maneira de evitar situações incomodas de um para um e possivelmente evitar ter a outra pessoa a passar a raiva e frustração.
  • Transfere a responsabilidade do remetente para o destinatário. Por exemplo, atribuir uma tarefa a outra pessoa e assumir que será sua tarefa executar o trabalho de forma a atender às expectativas, sem ter um confronto real com o destinatário.

Questões com a comunicação com email

Apesar de ser rápido e fácil, a comunicação através do e-mail traz inúmeras desvantagens e pode convidar a sérios problemas. Os gestores de projeto devem considerar os seguintes problemas antes de optar pela comunicação por e-mail:

Canal de comunicação impessoal: com o e-mail, estabelece-se uma conexão emocional superficial, e pode ser muito difícil expressar para o recetor as intenções desejadas, a menos que já tenham uma forte conexão profissional e emocional. O e-mail também é um canal desafiante para expressar a importância ou seriedade de várias tarefas do projeto. Com base nesses desafios, pela primeira vez, deve evitar o email na comunicação ou na comunicação com pessoas menos conhecidas. Além disso, se quiser discutir uma questão importante com implicações emocionais, os e-mails definitivamente não são um meio efetivo.

Meio assíncrono: o e-mail só fornece autoridade de envio para gestores de projeto, altos funcionários e líderes de equipe; eles não têm um controle total sobre o tempo de resposta. Em projetos sensíveis ao tempo em que a resposta rápida é esperada, a comunicação por e-mail pode causar sérios problemas relacionados à linha de tempo envolvendo tempo de recebimento, tipo de conteúdo, detalhes faltando etc. Além disso, não é um meio eficaz para incentivar ou gerar a resposta desejada de um recetor.

Problemas de contexto: com e-mail, é muito fácil desviar a atenção do significado desejado da conversa. Também em muitos casos, um recetor encaminha um email para outra pessoa que é incapaz de entender o seu contexto e também a sua seriedade. Tais situações levam a conflitos e complexidades indesejáveis ​​na gestão de projetos.

Canal inconsistente: o email é um canal inconsistente para partilha, especialmente quando compartilha documentos críticos entre os membros da equipa do projeto. As pessoas podem facilmente compartilhar e / ou enviar documentos antigos ou errados com diretrizes impróprias ou desatualizadas; tais situações podem facilmente criar percalços desnecessários e atrasos do projeto.

É por isso que acredito que o papel do e-mail deve ser restrito ao fornecimento de atualizações, e devemos considerar a inclusão de ferramentas colaborativas mais dependentes, como Sharepoint, Onedrive, Google Drive, Dropbox, etc. ou sistemas de gestão de documentos. Essas ferramentas fornecem clareza sobre documentos compartilhados e servem como um ponto de referência preciso para aceder a todos os tipos e versões de ficheiros partilhados. Também fornece acesso controlado ao documento garantindo a segurança das informações.

Falta de controle: o destinatário recebeu o correio? O email foi compreendido? Havia uma resposta? Se a resposta foi enviada usando "resposta" e não "responder a todos", a resposta deve ser encaminhada? Multiplique isso para qualquer destinatário na lista de distribuição!

Claro, não estou a afirmar que devemos parar de usar e-mails! Eles ainda podem ser úteis para manter o fluxo de comunicação, entregar atualizações, anúncios periódicos e enviar pensamentos motivacionais. Mas devemos ter cuidado, uma vez que, como já estabelecemos, o e-mail não é uma ferramenta eficiente para atribuir e controlar tarefas críticas do projeto ou comunicação. Para isto, as ferramentas colaborativas são de longe a melhor escolha e a carta é, ainda, a forma contratual de comunicar opiniões e propostas/decisões.

Tradução para português de Blog de Fausto Giani

domingo, outubro 22, 2017

Planeamento de projetos: vale mesmo a pena o trabalho?

Queira ou não queira, poucos eventos bem-sucedidos, viagens - e grandes projetos já se realizaram sem um problema na falta de um plano esforçado.
De acordo com o PMBOK, primeiro vem a fase de iniciação do projeto, onde o charter do projeto é desenvolvido e as partes interessadas são identificadas, depois segue o planejamento. 
Além de integrar todo o contributo das várias partes interessadas, o plano do projeto tem de explicar parâmetros adicionais, como o custo, o tempo, a qualidade, a coordenação, a comunicação, a disponibilidade de recursos e os riscos potenciais.

Quando se debate a importância do planeamento de projetos, pergunte a si próprio: "Quais poderiam ser as consequências de um planeamento inadequado?". Verá de imediato que o planeamento do projeto tem um impacto em todos os fatores do projeto.

A melhor abordagem para demonstrar a importância do planeamento do projeto é destacar seus benefícios:
  • Um plano oferece uma visão centralizada para o projeto, que capacita os membros da equipe a trabalhar em conjunto com o objetivo de atingir com sucesso um objetivo.
  • Com a visão, vem a clareza. O plano oferece um roteiro de como essa visão será alcançada através do planeamento das responsabilidades e tarefas dos membros da equipe e outras partes interessadas, com os cronogramas correspondentes. Isso cria claridade e responsabilidade para todos os envolvidos.
  • Este roteiro com instruções claras evita distrações externas para assumir as principais atividades do projeto.
  • Se alguém ou algo segue a via errada, podem voltar ao mapa para encontrar o caminho.

E com tudo documentado num só lugar, o plano atua como uma poderosa ferramenta de comunicação para manter todos os membros da equipa e as partes interessadas na mesma página.

Os planos nem sempre são perfeitos, mas raramente falham como um todo. À medida que entram em jogo os fatores que afetam o plano original, os detalhes do plano podem necessitar refletir essas mudanças -- e está certo. Os planos podem e devem ser revisados regularmente para que possam continuar a funcionar como um roteiro com marcos e cronogramas fundamentais para chegar lá.


Fica claro que com o planeamento do projeto obtemos um mapa comunicado às partes interessadas.

Pode continuar este tema explorando - O que é o Planeamento?

Para uma visão mais metodológica pode explorar - Gestão de Projetos - Um reforço da visão

segunda-feira, agosto 28, 2017

Breve Introdução ao EVM

A chave para abrir a porta a uma infinidade de métricas de status do projeto é o Valor Ganho (EVM). Esta é uma maneira de colocar um valor no progresso do trabalho alcançado. Mas como é obtido/ganho o valor especificado?
Muito na gestão do valor ganho (EVM) depende do valor monetizado que você coloca em trabalhos realizados ou no progresso em entregáveis.
Vamos apresentar brevemente o valor ganho para suportar o EVM mais simples.

Gestão do Valor Ganho

A EVM é uma maneira de quantificar o progresso do projeto com comparação do progresso real com o progresso planeado e o custo real gasto. A EVM desloca estrategicamente o ponto de vista de planeado versus real (acompanhamento tradicional usado em organizações não-EVM) para planeado versus ganho versus real.

Valor Planeado

A maioria dos projetos vem com orçamentos. Portanto, mudar a perspetiva dos entregáveis planeados, o valor planeado não é um salto particularmente difícil de fazer. O valor planeado é o orçamento ou o custo acordado do projeto e como ele será gasto ao longo do tempo.
Um conceito fundamental no EVM é que o trabalho vale o valor planeado (orçamento) do trabalho. O valor planeado simplesmente indicado é quanto valor você planeou ganhar num determinado momento. Por exemplo, você planeou gastar 6000 € para instalar um gerador diesel num barco. O valor planeado é, portanto, de 6000 €. Por definição, quando esse trabalho estiver 100% concluído, valerá 6000 € para o projeto.

Valor Ganho 

O valor ganho mede o progresso entregue em termos monetários (valor do trabalho realizado), e isso permite que o gestor do projeto quantifique o progresso como um valor monetário. Qual a utilidade disto? Uma vez que pode colocar um valor monetário no progresso alcançado, pode compará-lo com o valor planeado e o custo real. Esta mudança de perspetiva de percentagem de conclusão para o valor do trabalho realizado ou do valor ganho é uma mudança no pensamento que contribui significativamente para a análise EVM.
O valor ganho é uma forma de colocar um valor monetário no progresso do trabalho alcançado. A métrica de valor ganho é fundamentalmente um valor total percentual em euros. Em vez de dizer que uma entrega foi completada numa data especificada, o valor ganho diz um valor em termos de um montante em euros do projeto concluído numa data especificada. O valor ganho indicado simplesmente é quanto valor foi ganho efetivamemnte no projeto num determinado momento.
De novo, é uma mudança no pensamento para medir o progresso entregável em termos monetários (valor do trabalho realizado). Isso permite-nos traçar e comparar as três métricas (valor planeado, valor ganho e custo real) num único gráfico, o que, novamente, abre a porta para a análise que de outra forma, não é possível. Assim, pela medida do progresso entregável em termos monetários (valor do trabalho realizado), é possível projetar ou sobrepor o progresso do trabalho no mesmo gráfico que o custo orçamentado e o custo real, o que aumenta significativamente a possibilidade de métricas disponíveis.

Gráfico de Custo

Vamos em primeiro lugar decifrar a situação de agendamento a partir de um gráfico de custo e, em seguida, adicionar o valor ganho para mostrar como a adição do valor ganho proporciona uma melhor compreensão da situação verdadeira do plano. Na Figura 1, temos um gráfico de orçamentado versus  custo real ao longo do tempo ou plano de despesa versus de fundos gastos.
 
Figura 1
O custo orçamentado é o valor planeado do trabalho do projeto. Novamente, pense em termos de valor ou em termos económicos. Este gráfico mostra que os custos reais do projeto são significativamente menores do que os custos orçamentados. Parece que tudo está bem com o projeto - parecemos estar subestimando. Mas o que essa trama nos informa sobre o trabalho real concluído? Não muito; A percentagem do orçamento gasto ou o custo real não equivalem à percentagem do projeto completo. "A percentagem do gasto não é percentagem do feito". Então, ainda estamos no escuro em relação à situação de status.

Gráfico de Custo e de Valor Ganho

Agora vamos adicionar o valor ganho a essa trama para obter mais informação; o valor ganho contabiliza quer o custo do projeto como a situação de trabalho alcançada para colocar o valor no trabalho realizado. Este custo do projeto e a medição de progresso entregável em termos de euros fornece a valiosa terceira etapa, figura 2, para os lotes de custo orçamentado e custo real.
Figura 2
Quando adicionamos uma percentagem de conclusão em euros ou valor ganho para a nossa trama, observamos que a situação do cronograma real não é boa. O valor obtido a partir de setembro é significativamente menor que o custo orçamentado, então estamos atrasados. E o valor ganho a partir de setembro é menor do que o custo real, então nossa taxa de uso dos fundos do projeto é maior do que a taxa de progressão entregável; Estamos sobre o orçamento no trabalho concluído. O lote de valor gano revelou a verdadeira situação do    projeto, o que não é bom.
O gráfico de exercício mostra o valor em traçar a métrica de valor ganho e os custos em conjunto. Fornece uma visão de cronograma muito melhor e permite que uma análise que de outra forma não seria possível. A intenção aqui não é listar as muitas métricas de medição de valor ganho que ficam disponíveis a partir deste gráfico de três elementos. Essas métricas de gestão do valor ganho estão resumidas no Cartão de Ouro de Gestão de Valor Ganho da Defense Acquisition University.
Por enquanto queremos somente apreciar melhor o valor obtido ao discutir um projeto. No projeto de demonstração, acordou um contrato para construir 4 Quilómetros de via férrea por 400 mil em quatro meses com um contratado. No final de 3 meses, o contratado completou apenas 2 milhas de via com um custo de US $. ~
O gráfico apenas considera os custos orçamentados e reais, então dirá que no final de três meses você está 50.000 € acima do orçamento. Você gastou 350.000 quando foi orçado para gastar apenas 300.000. Mas esta análise apenas considera custos planeados e custos reais. O valor do trabalho alcançado não é considerado. O valor ganho considera o custo e o âmbito do trabalho alcançado em conjunto.
A análise do valor ganho diz que, a cada mês, devem "ganhar" 100 mil se estiverem no alvo por custo e cronograma. Infelizmente, em 3 meses eles apenas completaram 2 milhas de trilhos, pelo que seu valor ganho é de apenas 200.000. Bem, eles gastaram 350.000, então eles estão acima do orçamento em 150.000 e não 50.000. Também só completaram 2 milhas de trilho quando o programado para completar era 3 milhas, então estão atrasados em 100 mil. Esta análise de cronograma é refletida no gráfico de valor obtido para o projeto ferroviário, Figura 3.
Figura 3
A análise deste gráfico mostra uma variância de custo do valor real de ganhos de 150.000, o que é 3 vezes mais a variação de custo quando apenas considerando valores de custo e valor ganho. O planeado para o valor ganho em Euros é de 100.000. Note que o gráfico também exibe convenientemente o valor de tempo dessa variação de cronograma, 1 mês.

Sumário


Quando se trata de medir o progresso do cronograma, é comum considerar o âmbito completo ou os entregáveis submetidos. Se, no entanto, incluímos tanto o custo quanto o âmbito do trabalho alcançado juntos na medida de progresso chegamos ao termo útil no agendamento de valor ganho.

terça-feira, abril 18, 2017

Cálculo do plano do projeto

Após a definição dos tipos de contratos e a afirmação geral da necessidade do controlo dos contratos através do planeamento e controlo da sua realização tratamos agora da forma como os projetos são calculados, designadamente a sua duração e o caminho cítico.
Após a criação de uma rede e atribuída duração a cada uma das atividades, o tempo de início / fim é calculado para a atividade individual, bem como para todo o projeto. São calculados quatro tempos limite para cada atividade do projeto, conforme mencionado abaixo:
  • Early Start: é a data mais próxima possível quando uma atividade pode começar, permitindo que a duração necessária para as atividades anteriores a ser concluída.
  • Early Finish: é a data mais cedo em que uma atividade pode ser concluída.
  • Late Start: última data possível, em que uma atividade pode começar sem atrasar a conclusão do projeto.
  • Late Finish: última data possível em que a atividade pode terminar sem atrasar a conclusão do projeto.

Processo de cálculo

Calcular as datas é um simples método de adição e subtração, como:
       Forward Pass: Este é o primeiro passo numa rede para calcular as datas de early star & early finish para cada atividade. No início, o early star é atribuído à primeira atividade. Early finish é igual ao early start da atividade mais a sua duração. Presume-se que as atividades começam assim que as atividades precedentes imediatas forem terminadas. Portanto, para outras atividades, o early start é igual ao maior dos primeiros tempos de fim das atividades anteriores imediatas. Este processo de cálculo de forward pass continua até a última atividade do projeto ser alcançada, o que dá datas precoces para as atividades individuais e a data de término antecipada para o projeto total também.
       Backward Pass: Esta é a segunda etapa numa rede para calcular as datas de late start & late finish. Aqui, uma data de fim, ou o early finish calculado pela forward pass ou por uma imposição, é definido igual à data final da última atividade na rede. Então o late start para a atividade é igual ao late finish menos a duração. Além disso, o late finish de uma atividade é o menor dos tempos de late start das atividades seguintes. Supõe-se que uma atividade termina assim que todas as relações sucessoras imediatas estiverem satisfeitas. Esse processo de cálculo retroativo continua até que a primeira atividade do cronograma seja atingida para calcular datas tardias para todas as atividades.
A diferença entre o late finish e o early start ou o late start e late start é chamado de Total Float. Geralmente o Total Float é denominado como Float. As atividades com a menor quantidade de float são consideradas críticas. Idealmente qualquer atraso para essas atividades irá atrasar a conclusão do projeto, se nenhum esforço é tomado para recuperar o atraso.

Caminho Crítico

O Caminho Crítico é definido como o caminho mais longo, em tempo, das atividades inter-relacionadas ao longo do projeto. Uma vez que esta cadeia de atividades leva mais tempo para ser concluída, é fundamental para a conclusão do projeto. Por exemplo, se uma das atividades no caminho crítico for atrasada em dois dias e nenhuma ação corretiva for aplicada ao cronograma ou à atividade crítica, a data de conclusão do projeto será adiada por esses dois dias. O atraso envolvendo atividades que não estão no caminho crítico geralmente não tem impacto na data de conclusão do projeto, a menos que elas se tornem críticas devido ao atraso. No entanto, elas podem afetar a alocação / disponibilidade de recursos. O cronograma pode ser carregado com recursos / custos para realizar essas análises.
Free Float é definido como a quantidade de tempo que uma atividade pode ser adiada sem atrasar o início antecipado de qualquer atividade subsequente. Esta quantidade de tempo pode ser utilizada para a atividade retardar sem afetar a conclusão do projeto. Depois disso, a atividade pode se tornar crítica, sujeita à criticidade das atividades imediatas subsequentes.

O cronograma é atualizado regularmente com o progresso no site da obra e é revisto com quaisquer mudanças importantes na sequência de construção. É de suma importância manter planos atualizadas regularmente e analisar caminhos críticos com frequência. 

No próximo post tratamos das condições para garantir o cumprimento dos objetivos de tempo e outros do plano durante a realização das suas atividades.

terça-feira, abril 11, 2017

Implementar o Controlo do Plano

Continuação do artigo 'Tipos de contratos e impacto de atrasos' este é o segundo artigo. Queremos salientar que o controlo assenta num planeamento cuidado e que só assim se podem enfrentar os atrasos e as reclamações com sucesso.

O Fundamental do Controlo do Plano

Os atrasos podem afetar um projeto de várias maneiras. Um impacto é comum, é que todos eles custam dinheiro. Os custos indiretos de site e overhead aumentam. Trabalho que poderia ter sido realizado em tempo bom é empurrado para fora em tempo mau. Os obstáculos contínuos a uma tarefa podem reduzir muito a produtividade do trabalho e diminuir o moral dos trabalhadores. Os custos materiais e de mão-de-obra podem aumentar devido a atrasos substanciais.

Planeamento por níveis

São desenvolvidas várias planificações hierárquicas num projeto para monitorizar e controlar eficazmente e dessa forma evitar atrasos. A hierarquia define o sistema de controlo da programação e é mostrada na Figura 1 na página seguinte. Os planos de nível diferentes são detalhados abaixo, que são tipicamente usados para projetos de construção:
       Nível I: Este é o Cronograma de Milestones do Contrato. Geralmente uma página mostra a visão geral. É usado principalmente ao nível de Executivo das empresas para rever o projeto.       Nível II: Trata-se de um plano de nível resumido do plano de Nível III detalhado abaixo. A gestão senior no local de trabalho assim como no site usa esta programação para rever o projeto.       Nível III: O planeamento de nível III é geralmente o mecanismo de controle de todos os projetos. Esta é uma programação integrada para todas as funções e usada pelos gestores de departamento para revisão.       Nível IV: O plano de nível IV é um plano de trabalho detalhado com um nível mais baixo de detalhes em comparação com o plano de nível III. É normalmente usado para a revisão de progresso regular no local e é agendamento de nível de campo. Esta programação básica suporta todas as programações de nível superior. O projeto é controlado usando este cronograma e também é usado para análises de atraso.
Figura 1


Entre os vários métodos que estão disponíveis, o Método de Caminho Crítico (CPM) é o método de análise de programação mais popular, usado para acompanhar o andamento dos projetos de construção. A Figura 2 na página seguinte mostra uma rede CPM simples usando o Método do Diagrama de Seta. As atividades do projeto são mostradas por setas no método de diagrama de seta, com um Nó ou Evento em cada extremidade. As atividades levam tempo e recursos a serem executados e servem como os blocos de construção da rede.

Inter-relação de atividades

As atividades estão logicamente inter-relacionadas na rede e cada uma delas tem uma duração razoável. As durações devem ser estimadas com razoável certeza para que este método seja bem-sucedido. Para que uma atividade comece, todas as atividades anteriores imediatas devem ser concluídas. Se uma atividade começar antes que suas atividades precedentes sejam concluídas, a atividade deve ser subdividida para honrar a lógica da rede.
São usadas atividades simuladas apenas para mostrar relações entre atividades e não têm duração de tempo. Elas são usadas como restrições para as atividades seguintes.
A rede na Figura 2 mostra a sequência de atividades para montagem de equipamentos. Atividade A montagem não pode ser iniciada até que a placa de base seja instalada na base, o equipamento é entregue e o guindaste é montado ao local de trabalho. A linha pontilhada representa uma atividade simulada. É uma restrição para a atividade de ereção começar.
Figura 2

O próximo post trata do cálculo do projeto e designadamente a sua duração.