terça-feira, dezembro 23, 2014

A Implementação BIM e o Controlo do Projeto

As diferentes legislações nacionais irão gradualmente exigir a aplicação de BIM nas obras de construção e infraestruturas do setor público. No Reino Unido essa aplicação está orientada para se realizar já em 2016. Isso significa que os projetistas, empreiteiros e as cadeias de fornecimento na indústria irão necessitar de alterar as formas de trabalho e adaptar-se à nova legislação que sairá. No caso do Reino Unido a política é de pedagogia e não de punição. O objetivo é de adotar uma progressiva melhoria e com isso melhorar em paralelo de forma significativa a eficiência da indústria desde as fases de desenho, procurement, construção e gestão do projeto até à gestão operacional subsequente do ativo ao longo da sua vida.

O que é o BIM?

A utilização de desenho a 3D tem ajudado a indústria a coordenar as características arquitetónicas, a estrutura e os serviços de mecânica, elétricos para as obras públicas. O nosso mundo é tridimensional e, como tal, ser capaz de visualizar um espaço pelo designer, o construtor e o cliente dá uma reforçada interação em volta do ativo a ser construído quando se compara com as plantas, cortes e elevações tradicionais em 2D. O poder da modelagem em 3D permite identificar pontos críticos e detalhes de planos e secções. Além disso, o modelo 3D pode ser ligado com um plano de trabalhos para mostrar uma simulação de como se pretende construir o edifício ou infraestrutura (a modelação 4D). Se dermos um passo mais à frente e introduzirmos os custos no modelo adicionamos uma nova dimensão – agora é 5D, desta forma a informação de controlo do projeto fornece índices de custo e performance conforme se atualiza o modelo.

Um dos principais desafios de incorporar toda esta informação é a capacidade de integrá-la a partir de sistemas diferentes: o modelo 3D do ativo, a informação de higiene e segurança, o plano de trabalhos de construção, a lista de quantidades, o sistema financeiro, o sistema de gestão de ativos. O facto de ainda existirem questões de compatibilidade simplesmente na importação / exportação entre ferramentas como o Primavera P6 e o Excel – para além do complexo processo de integração de cliente / utilizador para colocar o Primavera a trabalhar com a gestão de custo do Deltek Cobra – sugere que estamos num mundo muito longe da total compatibilidade que o modelo BIM exige para alcançar o BIM 5D.

Gestão da Informação – sempre na raiz do problema

Podemos pensar que o problema reside na falta de integração entre sistemas de TI para os diferentes processo requeridos para realizar o projeto. A questão reside muito mais longe daqui. É a falta de uma estratégia de gestão da informação entre diferentes disciplinas que interagem no projeto. Esta visão apoia-se ainda nas sumulas das diversas conferência de gestão da construção que acompanhei. Demasiados processos exigem a duplicação de esforços no decurso do ciclo de vida do projeto que deveriam poder ser evitados se fosse adotada tal estratégia de gestão integrada da informação do projeto logo a um nível comparável a um PMO. Esta lacuna gera ineficiências que corroem as já reduzidas margens da indústria.

Como exemplo, deixem-me descrever a realidade nas nossas empresas no que se refere a esta omissão. Os empreiteiros são obrigados contratualmente a reportar as quantidades instaladas relativamente às planeadas para suportar a percentagem física de conclusão dos trabalhos que irão informar os índices dos controlos de performance do projeto. Isto significa que a Lista de quantidades necessárias trem de ser mapeada no plano do Primavera P6. Contudo, o estimador e o planeador durante o período de definição do plano da obra não falam um com o outro e a informação que produzem (Mapa de Quantidades e Plano) está de forma consistente desalinhada. Não são atribuídos códigos de custo às atividades do projeto. As folhas de abertura de trabalhos, na maior parte das vezes, não têm qualquer referência a um número de desenho. Em resumo, uma enorme confusão para qualquer pessoa que queira fazer algum sentido do quando e onde as quantidades de construção serão instaladas.

Na investigação do sentido do trabalho desta obra, quando se procuram o estimador e planeador do plano comercial para obter a informação, a mais das vezes estão já em novos contratos, quando não saíram da companhia. Vai então recorrer-se a novos recursos para por em ordem toda esta informação sem sentido e estes percorrem toda a informação para compreenderem o desenho do projeto, a sequência de construção e as suas relações com as atividades do plano do projeto, mapa de quantidades e até as folhas de abertura de trabalhos. Em todo este retrabalho perde-se tempo valioso para realinhar o Mapa de Quantidades com o plano, por forma a poder reportar de forma adequada e em conformidade com o contrato.

Esta situação ocorre com os empreiteiros com processos e ferramentas apropriadas, mas a realidade, na maioria dos casos, estes utilizam ferramentas de planeamento que não mapeiam nada disso e que com muita dificuldade conseguem fornecer informação confiável ao cliente – o projeto vive assim numa mentira com folhas de cálculo a serem trocadas e com percentagens definidas de forma quase aleatória. Portanto, os projetos não são geridos numa forma conforme ao contrato e os resultados enfermam de toda esta ficção.

Ineficiências e falta de produtividade

Há muitas ineficiências observadas na indústria, tal como as questões descritas acima na forma de realização dos contratos, até à dupla aquisição de materiais e desperdício, sequenciação inadequada da construção, retrabalhos, só para enunciar algumas. BIM visto unicamente como uma ferramenta não é a solução destas questões. A solução é a implementação de uma estratégia de integração da informação dentro das organizações que possa fornecer informação consistente e compatível alinhada com os requisitos das diferentes etapas do ciclo de vida do ativo. A definição desta estratégia ao nível do PMO que estabelece a solução apropriada de gestão da informação é a chave deste desafio, tal como é a disponibilidade de recursos competentes para a implementar e gerir. Muito mais fácil de dizer do que fazer, claro!

Assumam que desde da etapa inicial de um projeto a solução de gestão de informação é considerada em linha com os requisitos BIM do cliente. Se a solução é implementada desde a etapa de proposta comercial irar reduzir o tempo despendido e os esforços sujeitos a erro de ligar as peças diferentes depois de o contrato ter sido atribuído ao empreiteiro. O projeto poderá então progredir através das suas fases de vida do desenho, à construção e à operação, tendo cada interface os próprios desafios de integração. Ao nível do PMO, estes desafios devem ser enfrentados o mais cedo possível na vida do projeto e resolvidos através da inclusão das ferramentas apropriadas nos diferentes processos de gestão.

Muitos empreiteiros orgulham-se da sua utilização ocasional da modelação 3D na realização de um ativo para um cliente. Devem lembrar-se que este é só o primeiro passo na redução das ineficiências da indústria, e só uma parte pequena do âmbito que o BIM pode realizar. Os exemplos desta utilização – embora muito poucos – surgem em áreas como a saúde, a segurança, gestão de risco e da qualidade e mostram o valor do BIM como uma inestimável ferramenta multidimensional.

Em conclusão

A junção da estratégia de gestão integrada da informação com os controlos do projeto irá melhorar a exatidão dos KPI e, se realizada de forma correta, poderá ser o primeiro passo para a criação de uma base de dados de imenso valor comercial (com informação estatística sobre a performance de todos os tipos de trabalho). A integração BIM estará sempre condicionada à junção de desenhos, planos, custos e sistemas financeiros. Esta estratégia BIM deverá poder integrar todos os requisitos globais da indústria.

segunda-feira, dezembro 08, 2014

Integração de planos num megaprojeto

Um megaprojeto refere-se a um projeto que cobre áreas de trabalho múltiplas e que envolve geralmente um alto nível de despesa e uma duração que se estende por vários anos.

A primeira questão que se coloca quando pretendemos colar e consolidar múltiplos cronogramas é compreender o que queremos alcançar, ou seja, qual é a forma como o projeto vai ser realizado. Em muitos casos, estamos a tratar da definição do mecanismo que conseguirá agrupar toda a informação detalhada num só local. Toda a informação pode depois ser usada para gerar relatórios sumários de dados ou relatórios vários para apresentar aos vários stakeholders.

Esta agregação resultará quando conseguimos por esta forma mostrar aos stakeholders que o projeto progride, com dados estatísticos de milestones alcançadas relativamente às remanescentes.
 

Como configurar cronogramas para integração

A integração dos planos requere para ser alcançada:

  1. Uma estrutura
  2. Um conjunto de regras
  3. Garantir o cumprimento das regras.

Em primeiro lugar, a estrutura deve ser a hierarquia das áreas, funções e / ou fluxos de trabalho e baseia-se na estratégia definida de realização do projeto. Dentro de cada elemento da hierarquia deverá haver um conjunto de atividades que estão de forma lógica ligadas com pontos de controlo e milestones.

Em segundo lugar, as regras devem incluir:

  • Uma identificação para cada plano da área a que respeita: um código que identifica os planos individuais;
  • Um dicionário dos dados que identifique qual a informação exigida e em que campos;
  • A definição dos critérios de aprovação para as milestones ou resultados para garantir a consistência da conclusão:
  • As limitações e fronteiras do que pode e não pode ser mudado (e quem deve rever e aprovar) o que é uma combinação de controlo de configuração e controlo da mudança;
  • O ciclo de manutenção e revisão conforme o ritmo adequado.

Estas regras devem ser estabelecidas o mais cedo possível e comunicadas a todas as equipas envolvidas no megaprojeto. As regras devem ser fáceis de entender e aplicar.

Finalmente, estabelecidas as regras deverá existir um nível de «policiamento» e verificação do seguimento das regras. Basta que só uma área do projeto faça uma coisa diferente para haver um impacto muito grande em todo o megaprojeto.

Em alguns casos, a verificação do cumprimento das regras pode ser uma auditoria dirigida por um conjunto de critérios que atuam como uma porta (gate) e definem o mínimo standard que tem de ser aceite antes de realizar a consolidação com sucesso.
 

Benefícios da integração de planos

¶ O benefício mais significativo para uma organização de ter um plano integrado é a visibilidade melhorada sobre os dados do projeto. Esta visibilidade permite a geração de sumários a partir dum único local o que permite rapidamente identificar as áreas que não estão alinhadas ou desenvolver a confiança no cumprimento do trabalha em seguimento do plano.

¶ As organizações podem ainda realizar auditorias nos planos para identificar erros ou anomalias e, por estarem os dados numa localização única, é mais reduzido o número de vezes que se exige para esta verificação.

¶ O resultado obtido será mais consistente entre as várias áreas do plano do megaprojeto graças à integração dos planos.

¶ A integração dos planos permite mostrar interfaces e dependências entre os diferentes planos.

¶ A integração dos planos oferece continuidade ao megaprojeto mesmo com a mudança de elementos individuais das equipas, o que tem alta probabilidade quando o projeto dura vários anos.

Problemas com a integração dos planos

¶ Será necessário mais tempo de preparação para agrupar os planos individuais para garantir os standards requeridos. Este tempo adicional deve ser concedido quando se realiza o ciclo de atualização.

¶ Potencialmente pode ser necessário reunir muitos dados para garantir a identificação das questões reais – o foco pode estar mais na quantidade de informação, isto é, milestones alcançadas mais do que as milestones estão a oferecer como caminho do progresso.

¶ A abordagem de «policiamento» pode ser vista como apontar para mentalidade de resposta formatada em vez de enfrentar as questões do plano já que o foco pode estar na conclusão dos standards em vez da recolha efetiva de informação necessária às equipas.

¶ Com os detalhes incluídos no plano integrado deverá haver uma forma simples de sumarizar ou filtrar para mostrar níveis mais gestionáveis ou pode ser um trabalho imenso.

¶ Informação adicional é requerida para ser guardada para garantir que quando os membros da equipa mudam as assunções e a base do plano não são perdidas.

Conclusões

Em muitos dos casos, um plano integrado pode ser benéfico para uma organização e para a conclusão com sucesso do projeto, muito embora resulte sempre num interface com milhares de linhas. A chave para manejar grandes quantidades de dados é garantir que se recrutam pessoas com as competências adequadas na equipa de forma a garantir que o projeto não fica sem controlo. Finalmente e mais importante é essencial acordar desde o início se a quantidade da informação pode ser usada de forma construtiva para evitar o debate entre quantidade e qualidade dos planos.

Luís Quintino

sexta-feira, novembro 21, 2014

Realizar o Plano

O propósito deste post é apresentar uma metodologia o mais fácil possível para enfrentar o planeamento, a estimação do tempo e do custo do plano de um projeto.

A meta é chegar rápida e facilmente a:

  • Identificar o que significa «feito»
  • Identificar quando o «feito» pode ser feito.
  • Identificar quanto custa «feito» (para obter financiamento)
  • Identificar quem necessita estar envolvido em realizar o «feito».

Presume-se que os leitores têm familiaridade com ferramentas de planeamento como o Primavera P6 ou o Project. Para o nosso caso, utilizamos o Primavera P6.
 

Planeamento

Reúna uma lista de resultados. Esta lista é preferível a uma lista de atividades, ou seja, esta é a lista de elementos que temos de realizar para chegar a um resultado. Deixe que as atividades sejam o domínio das pessoas que fazem as atividades. Focalize-se em identificar e denominar os resultados. Inclua todos os componentes até aqueles que necessitamos para a mitigação do risco. Na engenharia, usualmente o contrato e o SoW são referências importantes para esta lista.

Olhe para o calendário. Uma ferramenta de planeamento é boa para isso e permite a sua real adaptação do trabalho às condições. Incluir tempo a mais no calendário não é boa prática porque cria estimativas erradas para o «feito».

  

Configure o plano

Importe a lista de resultados como elementos do plano, da WBS.

Adicione ao plano uma milestone de início e uma de fim.

Na lista de resultados que corresponde à sua WBS defina, no interface de Atividades, um mínimo de atividades, por cada um, que preencha o tempo total previsto para a sua realização mantendo o detalhe no mínimo necessário. Estamos a criar o plano global do projeto.

Ligue essas atividades entre si com recurso às funcionalidades de ligação em Finish to Start. Evite criar muito detalhe e mantenha tudo simples.

Use para as atividades os seguintes campos de configuração:

  • Tipo de atividade: duração fixa, para deixar o computador calcular as unidades a partir da duração do trabalho.
  • Tipo de percentagem de conclusão escolha a física para se responsabilizar por todas as entradas de dados – não é boa opção deixar a máquina fazer a introdução de status por si.
  • Duração: escolha em dias, não misture unidades de tempo dentro do plano.
  • Ligue as atividades de forma a todas terem sucessor e predecessor.
  • Utilize um Recurso Non Labor para definir um peso para as atividades que inclua uma ponderação (de duração x custo x intensidade dos recursos). Pode evoluir nesta classificação de acordo com outra informação recolhida no projeto como orçamento, estimação de duração, etc.
  • Inclua Milestones de aprovação, quando necessário, designadamente as relacionadas com Gates do plano. Muitas indústrias utilizam esta forma para passarem etapas ou estágios do projeto.
  • Crie uma lista geral de recursos a utilizar no projeto. Lembre-se que estamos a planear em alto nível e o que queremos é ter alguma sensibilidade para os totais de horas de trabalho ou de máquina a utilizar para determinadas atividades. Muito mais importante do que saber quem vai trabalhar é definir a capacidade necessária para o realizar.
  • Atribua os recursos – por equipas, por exemplo – às atividades de cada resultado.

Veja e trabalhe sobre os resultados

  • Calcule o plano, analise os resultados. Faça qualquer alteração ou adaptação conforme as necessidades ou as contribuições dos membros da equipa.
  • Faça uma análise à distribuição das ponderações do Recurso Non Labor criado para assumir os custos através de um relatório dos recursos atribuídos (Resource Assignement), ou uma folha em Resource Usage.
  • Faça a mesma análise às Horas Homem dos Recursos atribuídos, por mês e semana, para as verificar distribuídas.
  • Veja o Caminho Crítico o que lhe vai permitir ver a data em que se prevê que o plano seja concluído e quais as atividades que estão no caminho crítico. Se não estiver de acordo com os resultados volte a planear.
  • Veja a Resource Usage em spreadsheet e em gráfico (Profile).

Em seguida

  • Reveja o cronograma resultante em função da disponibilidade de recursos.
  • Reveja o cronograma em função das datas. Atualize se necessário o calendário para incluir todas as exceções (lembre-se das grandes festividades, dos períodos meteorológicos mais agudos, dos feriados, etc.). Reveja de novo e adapte.
  • Reveja o cronograma em função das expetativas dos clientes e da prontidão dos fornecedores. Os primeiros querem mais e os segundos oferecem sempre menos do que prometem.
  • Quando o plano está suficientemente completo, submeta-o para aprovação.
  • Após aprovação estabeleça uma baseline e comece a acompanhar o progresso em relação a esta.
  • Cumpra os intervalos de progresso definidos (semanal e / ou mensal) e atualize o plano – agora plano corrente – e compare-o com o seu plano original (a baseline).
  • Vá refinando com maior precisão o plano remanescente conforme vai progredindo.

 

A utilização do Excel

Algumas pessoas dizem preferir (e algumas vezes até se gabam disso) o Excel (ou equivalente) para realizar o planeamento dos projetos e mantê-los «simples». O que penso acerca disto é que sim, se estamos preparados para o fazer e estamos em condições de introduzir todos os cálculos necessários, porque não? Sei que isso não vai ser fácil e sei que em grande medida os algoritmos de uma aplicação de gestão de projeto só com imensa dificuldade podem ser incluídos em tal folha de cálculo.

Evite o Excel, em minha opinião, ou outros métodos manuais a não ser que esteja preparado para ter uma imensa quantidade de trabalho, trabalho que uma ferramenta de projeto pode fazer por si.

sexta-feira, outubro 24, 2014

Passos para introduzir um novo PMO

Implementar como um novo projeto organizacional um PMO (Project Management Office) é um sempre um grande compromisso. É também um grande investimento para a maioria das empresas, por isso é importante para realizá-lo com sucesso. As primeiras semanas e meses quando o PMO acaba de ser lançado são fundamentais para o seu sucesso contínuo. Queremos mostrar que fazemos a diferença e que a diferença é positiva!

Aqui estão quatro passos para alinhar o trabalho quando introduzimos um novo PMO para assegurar que começamos com o pé direito.
 

Passo 1: Comece devagar!

É uma coisa maravilhosa ter grandes ambições, mas é honestamente melhor começar pequeno. Um lançamento sem grandes focos em cima, pode ser mais eficaz do que uma enorme fanfarra. Introduzir alguns serviços essenciais em primeiro lugar e, em seguida, construir as bases para mais no futuro.

Esta abordagem gradual é exatamente o que deveríamos em um projetos de atividades múltiplas: comece com o básico, principais ofertas e adicione uma funcionalidade maior. Com projetos de mudança organizacional (como a introdução de um novo PMO) a necessidade de dar pequenos passos é ainda mais importante. Permite gerir a atividade de uma maneira que garante o apoio de todos e ajuda a que as novas formas de trabalho ’colem’. Também permite detetar precocemente problemas e tratá-los antes que se tornem muito difíceis. Se você pode identificar um problema, você pode controlá-lo e colocá-lo no lugar certo, ficando o lançamento PMO volta na pista com no caminho certo.
 

Passo 2: Obtenha suporte de topo

Fale com as partes interessadas chave. Muito. O propósito é obter suporte e empenho para o PMO e para aquilo que ele pode fazer, de preferência quase sempre longe das luzes de cena. As interações do PMO ajudam a construir um empenho positivo ao longo do tempo. Muito do que sevai fazer são reuniões um para um e conversas fora das discussões formais, assim quanto mais se fizer trabalho em rede de divulgação dos objetivos e sucessos do PMO mais simples será a transição para um PMO com base no negócio.

Se pensa que necessita de orientar a ação e definir planos claros de comunicação provavelmente determinará que há alguns intervenientes chave – pessoas com influência para influenciar ou prejudicar a sua iniciativa de PMO. Estas são as pessoas com que deve trabalhar. Venda os benefícios do PMO, peça conselho, incorpore as suas sugestões e mostre-lhe que resultado está a obter. Quando começarem a ver a diferença que o PMO está a fazer eles irão aderir.
 

Passo 3 – Introduza processos claros

É tentador introduzir um processo antes de estar na realidade completamente pronto: precisa, por exemplo, de ter em posição qualquer coisa para a gestão da mudança, então lance alguma coisa (qualquer coisa) e melhore-o mais tarde.

Esta abordagem tem a vantagem de colocar alguma da estrutura no lugar, mas também a desvantagem de ir ter certamente de voltar a trabalhar o processo num momento não muito distante do futuro. As mudanças constantes e atualizações tornam difícil para a equipa do PMO e gestores de projeto trabalhar exatamente como deveriam fazer. Mas é normal ter de fazer mudanças ao processo já que um novo PMO evolui e temos de tentar fazê-lo numa forma que se torne mais fácil para os utilizadores desse processo. Por exemplo, estabeleça uma data todos os meses (ou menos frequente) para a realização dessas novas mudanças. Faça um pacote das mudanças e realiza uma comunicação acerca dos processos novos ou emendados. Assegure-se que no dia em que as mudanças têm efeito todos os guias na intranet, ficheiros de ajuda e manuais de utilizador são também atualizados e que a equipa central do PMO está totalmente informada para poder suportar as pessoas relativamente às mudanças.
 

Passo 4 – Obtenha benefícios com rapidez

O novo PMO foi lançado por uma razão. Pode ter sido pata ter maior transparência, melhor tomada de decisão executiva, controlos de projeto mais apertados ou qualquer outra coisa, mas de certeza que não o lançámos de forma gratuita. Deve assegurar-se que pode evidenciar as melhorias que fez – e rapidamente.

Nem todos os benefícios do PMO são soluções rápidas. Alguns, como a introdução da Gestão do Valor Ganho (EVM), podem tomar vários meses e múltiplos projetos antes que comecemos a ter dados suficientes para avaliações mais acertadas ao nível da companhia. Mas devemos ser capazes de mostrar alguns benefícios nos primeiros meses da sua operação.

Quando estabelecer os planos de lançamento do PMO, pense acerca do que quer introduzir que possa mostrar rapidamente um «retorno do investimento». Mesmo um conjunto de modelos para a standardização da documentação de projeto ou o uso por todos os gestores de projeto da mesma ferramenta de gestão em vez de um conjunto de produtos podem ser medidas rápidas para mostrar melhorias e uma maturidade maior.

Assegure-se também que os seus stakeholders apoiantes estão conscientes de alguns dos outros benefícios do PMO. Seja transparente acerca de como acompanhamos estes benefícios e reporte regularmente o seu progresso.

Se tomar em conta estes 4 passos verá que o seu novo PMO deixará rapidamente de ser ‘novo’ e começa a ser ‘a forma de aqui fazer o trabalho’.

terça-feira, julho 08, 2014

Controlo do âmbito do projeto

Porque é importante evitar alterações num projeto - mas por que elas não podem ser totalmente evitadas?

Mudanças da baseline técnica do projeto devem ser evitadas tanto quanto possível, por duas razões:

· Em primeiro lugar, mudar os requisitos técnicos pode alterar o custo do que foi estimado na fase de oferta, e

· Em segundo lugar, as mudanças levam sempre a distúrbios e re-trabalhos, para todas as partes impactadas, que são muito mais prejudiciais e difíceis de avaliar do que os custos diretos.

São implementadas inúmeras mudanças durante a execução de um projeto. Algumas fazem parte da normal da execução do projeto e não podem ser evitadas. Incluem o desenvolvimento do projeto, a incorporação de informações de fornecedores, etc. Várias alterações, no entanto, podem ser evitadas. Estas são os pedidos feitos pelo cliente que são na verdade extras sobre as exigências contratuais.
 

Gerir as mudanças criadas pelo Cliente

Existem dois tipos destes pedidos. Em primeiro lugar, as mudanças reconhecidas, isto é, carta formal do cliente com um pedido de trabalho adicional, a implementação da nova exigência, etc., pedindo ao Contratado para fornecer uma estimativa do impacto do custo / cronograma e mudanças não-reconhecidas que vêm na forma de comentários sobre entregas, requisitos transmitidos "abertamente" por meio de cartas, registos em atas de reuniões ou comunicação informal (oral, e-mails etc.)

Mudanças reconhecidas são uma questão menor pois elas vão levar a uma compensação (tempo e dinheiro) a partir do cliente através de uma Ordem de Alteração do Contrato.

Mudanças não-reconhecidos são as mais numerosas. Eles são as mais prejudiciais para o Contratado pois são muitas vezes despercebidas e incorporadas por este no seu custo.

Fontes do setor estimam que as empresas Contratadas perdem entre 5 e 15% do valor do contrato devido a isso.
 

Como enfrentar estas Mudanças?

Primeiro que tudo, logo que detetar a mudança o Contratado deve solicitar ao cliente a receção de um pedido oficial.
A maneira prática de fazer isso é dar a seguinte resposta padrão a qualquer pedido, por exemplo, incluído como um comentário sobre um resultado do trabalho contratado:
"Este comentário constitui um requisito adicional ao contrato. (Explique por que, referindo-se aos documentos de contrato aplicável). Este pedido não será considerado, a menos Companhia emita um pedido oficial nos termos do artigo X do Contrato "Pedido de Mudança iniciado pela Companhia ".
Isto irá eliminar a maioria de tais pedidos, já que o cliente vai querer evitar os custos adicionais resultantes.
Irá ainda iniciar, para os restantes, o processo conducente à compensação do contratado.
 

Posição no caso de alterações não-reconhecidas

Caso receba o pedido oficial do cliente, ele pode ou não reconhecer que a solicitação feita é uma alteração ao contrato.

Se a alteração for reconhecida, o Contratado irá preparar a estimativa do impacto no custo / programação. Ocorrerão discussões com o cliente sobre tais estimativas. O desafio para o contratado será concordar prontamente com tal estimativa com o Cliente, e esta ser registada num pedido de alteração aprovado. O contratado poderá, ainda, tentar evitar o atraso da espera e prosseguir com a mudança sem um pedido de alteração aprovado.

Quando se sabe que em grandes projetos se leva, em média, um ano entre a data da receção da solicitação de alteração reconhecida pela Empresa e a do Pedido de Alteração aprovado, compreende-se que o contratado esteja exposto por um longo tempo a esta pressão.

No caso de o pedido não ser reconhecido como uma mudança ao contrato, o contratado deve notificar que ela constitui tal mudança. Se o Contratado não o fizer dentro de um determinado período de tempo, perderá o seu direito de ser compensado por um custo / tempo extra.

O Contratado poderá apresentar diretamente a estimativa de impacto do custo / tempo ou declarar que não irá considerar tal pedido, a menos que o Cliente o reconheça formalmente como uma mudança. Isso vai depender da vontade do contratado para implementar a alteração, o seu impacto e tempo / esforço necessário para avaliar.

Uma vez que a notificação / estimativa acima seja emitido, a resposta da Companhia deverá ser cuidadosamente acompanhada.

Tal resposta pode ser uma negação de que o pedido constitui uma mudança. Nesse caso, a Contratada não executará o pedido informal.

Há uma exceção a esta opção, quando a resposta do cliente contém uma instrução formal para o Contratado implementar a mudança. Os Contratos de fato, geralmente dão ao cliente esse direito para forçar o contratado a proceder a alterações e este tem o dever de cumprir.

O contratado deverá, em seguida, registar os custos incorridos para os reclamar ao Cliente.

Caso a resposta não contenha instruções para prosseguir, no entanto, ou no caso em que não haja resposta recebida do cliente, o contratado não deve implementar o pedido.

É essencial o acompanhamento adequado pelo Contratado da resposta do cliente e da comunicação a todas as partes interessadas acerca da possibilidade de aplicar a implementação da mudança ou não.
 

Conclusão

É fundamental que o Contratado implemente um sistema apertado para detetar os pedidos e solicitações do cliente designadamente os que constituem alterações ao contrato. Os contratados devem, de fato, apenas implementar as solicitações que são reconhecidas como mudanças perlo Cliente ou as que são forçados a implementar por instrução formal.

A inexistência de um sistema apertado, o que é bastante comum, resulta em perdas significativas para os contratantes.

quarta-feira, junho 04, 2014

Chegar a acordo com a Data de Conclusão

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

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

A data indicada

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

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

A data agendada do projeto

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

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

A data negociada

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

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

sexta-feira, maio 02, 2014

Porque é que os contratos EPC estão sempre com atrasos

Baseado em experiências recentes em contratos EPC com que entrei em contacto por motivos profissionais e confrontado com os atrasos de todos eles eis algumas razões para esta questão.

A forma mais comum de contrato na construção ou para instalações industriais é o EPC e assim podíamos referi-nos a EPC Contractors, mas não é assim?

Este conceito é enganador e está na origem das causas de atrasos sistémicos em projetos em EPC.

Podemos imaginar um empreiteiro de um EPC como uma companhia que abrange o conjunto total de atividades para a execução do projeto, desde o desenho até á colocação de todas as tubagens e equipamento no site.

Este modelo integrado até existiu, até à década de 80 do século passado, mas desapareceu entretanto. As companhias de engenharia primeiro cortaram nas suas equipas de construção e equipamento e depois na supervisão da construção.

Nos dias de hoje encontramos normalmente o EPC Contractor numa associação de duas companhias, uma fazendo a Engenharia (E) e o Procurement (P) e a outra a Construção (C).
 

Tipos de associações para um EPC

Existem 3 tipos de associações entre estas duas companhias: Uma Joint-Venture, um Consórcio ou um Subcontrato. A mais frequente é a última. O empreiteiro da Construção é o subcontratado de uma companhia de Engenharia, à qual foi adjudicado o Contrato de EPC.

Se analisarmos estes tipos de associação veremos a razão principal para os atrasos sistémicos da execução dos EPC.

A questão assenta com a forma como uma parte controla os custos faturados pela outra parte. É muito difícil para uma companhia de Engenharia controlar as horas homem de força de trabalho e equipamento faturados por um empreiteiro de Construção. Este empreiteiro muito provavelmente inflacionará estes custos para criar o seu lucro, independentemente daquele que obterá da Joint Venture.

O consórcio tem cada uma das partes responsável pelo seu âmbito, despesas e lucro. Isso fornece um incentivo para cada parte minimizar os seus custos. Há sempre uma cláusula de isenção que evita que uma parte possa reclamar da outra.

A questão assenta ainda no impacto que pode ser suportado pelo parceiro de Construção devido aos atrasos nos desenhos e entregas de materiais por parte da companhia de Engenharia. Estes atrasos resultam em mão de obra e equipamento parados. O empreiteiro de Construção não será capaz de reclamar este custo adicional da companhia de Engenharia. Sabendo isto, irá incluir estes custos na sua proposta o que irá afetar a competitividade do preço da proposta do consórcio. Mas este esquema não é muitas vezes visto…

Finalmente, o tipo mais comum de associação encontrado é o subcontrato. A companhia de Engenharia subcontrata as atividades de construção a um subempreiteiro de construção.
 

Subcontratos em EPC

O empreiteiro de construção é habitualmente pago aplicando taxas de unidade às quantidades instaladas, por exemplo, tanto por metro cúbico de betão, tanto por tonelada de tubagem erigida, etc. Isto significa que o empreiteiro de construção será pago uma quantidade fixa de dinheiro por uma dada quantidade de trabalhos realizado qualquer que seja a quantidade de recursos consumidos (mão-de-obra, equipamento). Em outras palavras, o empreiteiro de construção assume os seus riscos de produtividade.

A produtividade do subempreiteiro, contudo, está altamente dependente das entregas atempadas dos desenhos e materiais pela companhia de Engenharia. No caso em que os desenhos ou os materiais sejam atrasados, o subempreiteiro sofrerá tempos de paragem da sua mão-de-obra e equipamento, e como subempreiteiro continuará a ser pago a mesma quantia por cada tonelada de aço construída ou erigida e a mão-de-obra e equipamento terão de ser requeridos e mobilizados por um mais largo tempo.

Em teoria o subempreiteiro pode reclamar extensões de tempo e de custos inerentes. Estas reclamações são de facto tornadas possíveis pelo tipo de associação de subcontrato, ao contrário do consórcio.

Na prática, o subcontrato tem usualmente clausulas que dificultam a possibilidade de efetuar com sucesso estas reclamações. O subempreiteiro poderá ter de provar que os atrasos impactam o caminho crítico do agendamento aprovado.

Como as entregas da engenharia e dos materiais estão sempre sujeitas a entregas fora da sequência e muitas vezes atrasadas e é difícil que as reclamações referidas possam ser atendidas, o subempreiteiro tentará mobilizar um pouco mais tarde para poder atingir a mais alta produtividade.

Por outro lado, o empreiteiro EPC não será totalmente transparente com as esperadas entregas de desenhos e materiais já que o seu interesse está mais no progresso da construção do que na sua produtividade.

Neste conjunto de fatores reside o fator sistémico que conduz a atrasos nos projetos EPC organizados através destes esquemas contratuais.

Como este esquema é a norma, podemos deduzir que o cliente está mais preocupado com o preço do que com o agendamento e tem uma folga estabelecida no agendamento global para atraso na execução do Contrato EPC.

O esquema ainda seduz o empreiteiro do EPC a completar o mais cedo possível para evitar quer penalidades e multas quer extra custos devidos a uma prolongada estada no site.

Subcontrato por empresa de construção

Uma outra hipótese é o subcontrato ser liderado pela empresa de Construção que subcontrata a empresa de Engenharia para fazer o desenho. Aqui sucedem os problemas ao invés. Já não é a empresa de construção que tem dificuldade em dar resposta mas sofre na mesma dos atrasos de desenhos e entregas para arrancar com os trabalhos.

No fundo a empresa de construção líder do EPC vai ter as mesmas dificuldades de mobilização de acordo com o plano e o agendamento vai sofrer os mesmos atrasos.

Os problemas de coordenação são ainda complicados com a deficiente definição do âmbito e das soluções técnicas do projeto, que atrasam a Engenharia e a Construção.
 

Há algum caminho?

A melhoria da comunicação entre as diversas estruturas de parceria no EPC é a solução mais evidente. O líder do EPC tem de estabelecer um sistema transparente de planeamento, execução e controlo da obra através da utilização correta de ferramentas partilhadas e estruturas de dados comuns.

A responsabilidade dos atrasos quando conhecida é a melhor forma de ajustar o plano à realidade. O processo que tem mais sucesso nestes contratos é a aprovação em tempo de planeamento desenvolvido por níveis de complexidade. Esse plano é único e abrange todas as áreas do EPC.

O plano passará de um nível de topo até um estado em que os recursos com o detalhe exigido são incluídos no plano. Nos recursos inclui-se uma abordagem ao custo para que a performance de custo possa ser acompanhada relativamente á realização dos trabalhos.

Luís Quintino

segunda-feira, março 31, 2014

Gestão de Projetos –Um reforço da visão

Se você quisesse viajar para um lugar que nunca tinha visitado, não seria bom entrar no carro sem ter algumas indicações ou sem um mapa? Provavelmente não! Mais do que provável também, que gaste algum tempo para planear a viagem, considerar rotas alternativas e estimar a hora de chegada. Planear a viagem antes mesmo de sair irá ajudar a ter sucesso na viagem. E, ao longo do caminho, se você encontrar estradas cortadas ou atrasos no trânsito, já identificara caminhos alternativos para chegar ao destino.

A gestão de projetos segue a mesma metodologia e finalidade – para atingir os objetivos de cada projeto, precisa planear com antecedência. Boa gestão de projetos não é só uma opção nos dias de hoje. É uma ferramenta fundamental para ajudar a empresa a permanecer no alvo e atingir os objetivos que se propõe o que faz que a gestão de projetos seja transversal à economia e a todas as empresas.

Em suma, gestão de projetos é o processo de alcançar objetivos definidos, dentro dos limites de tempo, orçamento e restrições de pessoal. Ele permite que obter o máximo retorno dos recursos disponíveis. Os recursos incluem

  • ·Pessoas
  • ·Materiais
  • ·Dinheiro
  • ·Equipamentos
  • ·Informações
  • Instalações

O processo de gestão de projetos é guiado por três princípios fundamentais:

  • Planeamento
  • Controle
  • Gestão

 

Planeamento de um projeto

O primeiro passo na gestão de projetos é o de definir o seu projeto.

  1. Qual é o âmbito total do trabalho? Que atividades compõem o projeto e qual é a sua relação com o âmbito? Vai querer identificar os principais marcos que ajudarão a monitorar o progresso do projeto.
  2. Qual é a duração do projeto? Quais são as datas em que o projeto começa e termina?
  3. Quais são os recursos disponíveis para o projeto? Além do trabalho, pensar em todos os tipos de recursos que vai exigir.
  4. Quem vai executar e que atividades? Determinar os recursos de trabalho e as horas de trabalho disponíveis é uma parte fundamental da construção de um plano bem-sucedido. Precisa planear o tempo de inatividade e os feriados e determinar a semana regular de trabalho para os vários tipos de pessoal.
  5. Qual será o custo do projeto? Quais são os custos por recurso? Existem custos ocultos do projeto?
  6. Qual é o orçamento estimado? Estabelecer uma estimativa de orçamento do projeto com antecedência ajuda a monitorizar possíveis desvios de orçamento.

As respostas a estas perguntas formam a estrutura do seu projeto.

 

Controlar um projeto

Depois de ter construído o plano e estimar as necessidades de orçamento, guarda este plano original como uma linha de base, ou cronograma alvo, para ajudar a controlar o projeto. Uma linha de base fornece um sólido ponto de referência de como se agenda as mudanças ao longo do tempo. Permite que compare o cronograma original com o atual e identifique as mudanças significativas e desenvolver dessa forma planos de contingência.

Controla-se um projeto para mantê-lo na direção certa. Vamos querer acompanhar o progresso do trabalho e custos, compará-los com a sua linha de base, e então recomendar que ações devem ser tomadas.

O controlo efetivo do projeto recolhe muitos benefícios. Permite que se mantenha um olhar atento sobre os problemas possíveis antes que eles se tornem críticos. Permite que a equipa de projeto e a gestão de topo vejam as escalas de custo e de tempo com base na realidade do plano.

 

Gerir um projeto

O processo de conduzir um projeto do início ao fim é da responsabilidade de um gestor de projeto. Um bom gestor de projeto usa muitos chapéus, atuando em vários momentos como um motivador, comunicador, coordenador e orientador. Como controlar o andamento do projeto é o maior trabalho a realizar, para manter sua equipe ciente das mudanças no plano e possíveis consequências. De muitas maneiras, o gestor de projeto é embaixador do projeto, garantindo que a organização que dirige o plano permite a realização das suas responsabilidades para o melhor resultado possível.

Para ser um gestor de projeto eficaz também se exige coerência quando atualizar seus projetos. Escolha um dia certo em cada semana, ou a cada duas semanas para atualizar regularmente projetos. Esta atualização regular irá incluir progresso em valores como a

  • Datas em que as atividades são iniciados ou terminadas
  • Datas em que os recursos são consumidos
  • Alterações para as taxas de recursos

A empresa deve determinar uma política padrão que o gestor realiza para a atualização e um procedimento de agendamento e para relatar o progresso.

terça-feira, março 04, 2014

Reporting de Risco em Projetos

Os projetos devem ser reportados ao cliente com regularidade, semanal ou mensal. A maioria deles têm muitas vezes regras predefinidas com alguma profundidade para medida do trabalho realizado e seu controlo. Este é o reporting normal de progresso, mas se precisarmos de reportar os riscos e as questões em aberto, como devemos fazer?

 
As normas de gestão de projeto têm alguma orientação para reporting de informação de risco?

Não. A prática de risco do PMI não inclui nada e o PMBoK fala só acerca de relatórios de performance, mas não fornece nenhum detalhe sobre o que devem estes relatórios incluir. Assim, cada um e em cada caso deve ser definida o conteúdo dos relatórios.

 
O que deve ser incluído num interface gráfico de gestão de risco?

Para um relatório para a gestão sénior só deve relatar os riscos em aberto por projeto e / ou os riscos em aberto por categoria (âmbito, orçamento, plano, etc.). isto irá permitir ver se há uma área como o plano em que há maior impacto de risco nos projetos.

Não incluir:

  • Número total de riscos gerais
  • Riscos fechados
  • Riscos com um status de impacto baixo ou médio

A razão para isto é que a gestão sénior não pode fazer muito, se alguma coisa, com esta informação. O número de riscos é por si só uma informação sem significado. Alguns podem ser muito pequenos, alguns projetos podem só ter uns poucos mas podem ser muito significativos. Uma forma melhor seria reportar sobre o impacto do risco – qual o custo de todos estes riscos se ocorrerem?

A abordagem mais adequada será confirmar junto da gestão qual a informação que lhes interessa ver. Não penso que o número de riscos ou os riscos fechados seja informação que eles necessitam para tomar decisões acerca do projeto. Os riscos por categoria, ou riscos com classificação de impacto «alto» são muito mais significativos.

 
Devo mostrar as tendência do risco ao longo dos meses?

Não. O que vai a gestão fazer com esta informação? No início do projeto são identificados muitos riscos e depois fechamos alguns e abrimos novos. Se num determinado mês se realiza uma revisão dos riscos e se identificam mais 50 as tendências vão ficar todas baralhadas. O melhor será em termos de tendências mostrar a situação para um período largo de tempo. Pode utilizar-se uma seta para indicar se o perfil de risco global do projeto está a subir ou a descer, ou usar uma métrica para mostrar se há mais ou menos riscos de «alto» impacto ou se as implicações de custo decorrentes da mitigação de risco subiram ou desceram.

 
E então como reportar as questões e problemas?

Para a gestão sénior só deve mostrar as questões de alta prioridade e em aberto. Em termos de progresso, importa mostrar as questões de «alta» prioridade fechadas durante este mês. Isto mostra o progresso que se está a realizar na resolução de questões, mesmo quando surgem novas questões. Se não fizer dessa forma, o relatório mostrará que existem 20 questões abertas com um status de «alta» prioridade este mês e novas 20 questões abertas. Contudo estas podem ser 20 questões completamente diferentes. Sem muito mais detalhe, como nomes das questões e descrição (o que certamente os sponsors não tem interesse em percorrer), não será fácil ver que estamos a resolver as questões e podem assumir que não estamos a enfrentar os problemas no projeto.

Incluam também as 10 mais importantes questões, com descrições a planos de ação. No caso em que o input dos sponsors é importante para a resolução das questões, não nos podemos esquecer de as incluir no relatório e são salientadas as que necessitam da sua decisão.

Aqui a melhor abordagem é conhecer o que a gestão sénior tem necessidade e pretende saber. Para isso não há como perguntar. Se os sponsors não sabem, apresente-lhes os gráficos e relatórios durante alguns meses e depois peça pelo feedback sobre o que pensam e que mais informação acham que necessitam para desempenharem as suas funções no projeto – tomada de decisão, governação e supervisão.

terça-feira, janeiro 21, 2014

O que espera o cliente do projeto e da equipa?

Logo que começa o projeto, as expectativas de ambos os lados – cliente e equipa - são elevadas e positivas já que tudo é fresco, novo e perfeito. Os pessimistas podem dizer que não há mais nenhum lugar para ir senão para baixo. Na realidade, esta é quase uma situação perfeita com os clientes excitados com o projeto em mãos e, assim, tudo o que se tem de fazer é mantê-los com esse espírito. Pois, mas isso é mais fácil dizer do que fazer.

Temos visto e não poucas vezes que, após os tempos iniciais do projeto, se cria uma atitude «tecnicista» relativamente ao trabalho que afasta a equipa do cliente, e em que se menosprezam as suas expectativas afirmando que o cliente tem desconhecimento das condições ou dos efeitos.

Para que o projeto decorra bem há muitos papéis que o gestor de projeto vai ter de desempenhar ... seja o comunicador, gestor, repórter, decisor, equilibrista de risco e negociador. O cliente olha para estes papéis como a representação de algumas das exigências que são colocadas sobre o gestor de projeto conforme se inicia o empenhamento no projeto em curso. Eu penso que - do ponto de vista do cliente -, há algumas exigências básicas e mais específicas que espera do gestor de projeto quando ele inicia a liderança do projeto no seu caminho para o sucesso. Estes são ...

Comunicação Frequente

Nenhum cliente se sente confortável ​​acerca do estado do projeto quando o gestor do projeto não comunica. Esta é a razão que leva muitas empresas e gestores a serem relutantes em permitir as equipes virtuais e os trabalhadores remotos - eles sentem que se não os veem a funcionar ou não os ouvem o suficiente a falar sobre o seu trabalho, então eles provavelmente não estão a trabalhar o suficiente.

Uma estratégia de comunicação efetiva regular e eficiente deve ser aprovada e executada com elevada regularidade. O cliente tem de sentir que domina as situações por que passa o projeto e sabe que caminhos estão a ser tomados.

Disponibilidade a todo o tempo

Isto parece impossível, porque temos muitas outras coisas a fazer. Mas da forma mais clara e na maior parte do tempo, queremos que o cliente saiba que o seu projeto é único e que tem toda a nossa atenção. Devemos fazê-lo sentir que tem de nós a máxima disponibilidade.

Bom reporting de status

Não se deve deixar nunca o cliente só ao frio sem receber reporting de status. Um bom, claro, atualizado e informativo status é uma condição crítica. O cliente exige-o e espera que as suas expectativas sejam acompanhadas. O relatório semanal é o meio de o cliente justificar a viabilidade do projeto para a gestão de topo. Devemos elaborar o relatório como se devesse ser visto por centenas de pessoas, como se fosse um artigo de jornal. Boa e esclarecedora leitura.

Uma equipa que sabe o que está a fazer

Os profissionais que escolheu para a equipa estão preparados para entregar uma solução de alta qualidade no projeto do cliente. É isso que o cliente espera do dinheiro que está a gastar desde o primeiro dia. Esta é também a atitude que o gestor do projeto tem de fazer ressaltar da atuação e performance da equipa. Qualquer coisa inferior a isso criará desconforto no cliente e levantará questões acerca da capacidade para realizar o projeto. Mantenha os erros, descuidos, conflitos e lapsos de comunicação num mínimo absoluto e conseguirá manter o cliente convencido que estão a obter o valor do dinheiro da equipa e do gestor do projeto.

Atualize o agendamento do projeto

Finalmente, prepare o cliente para receber previsões atualizadas do agendamento do projeto todas as semanas. Sobretudo se for necessário prócer a mudanças críticas. Nunca assuma que o cliente não olha ou não sabe ler o cronograma do projeto. Podem até não olhar para ele muitas vezes … porque confiam no nosso bom reporting de status, mas não se esqueça que um cronograma é para muitos clientes como que uma obra de arte, podem não o examinar em muito detalhe e podem mesmo não o compreender totalmente ou interpretá-lo com correção, mas é um grande gráfico para pendurar na parede e dizer à gestão de topo «Olhem o que estamos a realizar!».

quarta-feira, dezembro 04, 2013

Não culpem as pessoas! Culpem os processos!

Ter bons processos confiáveis ​​é a pedra de toque para um negócio com sucesso. Os processos estão lá para garantir que há consistência e robustez para as actividades repetitivas.

No entanto, nem todos os processos são bons processos e, no pior dos casos, podem realmente fazer recuar o negócio. Isso ficou claro num projecto em que trabalhei recentemente ...

O projeto bloqueou porque o processo de implementação da infra-estrutura de TI não tinha sido devidamente comunicado e os decisores não foram identificados. O departamento de TI ofereceu uma ajuda muito reduzida nas fases iniciais do projecto. Logo, ficou claro que algo estava errado, especialmente porque os membros da equipa, que pretendiam o sucesso do projecto estavam a ser fortemente condicionados pelo próprio processo. Um caso claro de um processo mal pensado e pesado que atrasa um projecto importante para o negócio. Então que lições podemos aprender com isso?

 

O processo demorado

Não culpe as pessoas, porque você tem processos grandes e pesados​​. Pergunte se os processos estão adequados à finalidade. Se você estiver obrigar as suas pessoas a ultrapassar muitos obstáculos e eles resistem, então você está preso num "processo de corrida de obstáculos".

O que fazer: Rever e simplificar seus processos. Verifique se não há papéis e responsabilidades que sejam claros e você preste contas em todos os cenários e não apenas o principal. Teste a execução dos seus processos em papel com as pessoas que vão usá-los e melhorá-los a partir do seu feedback.

Como sabemos, bons processos são um caminho para o sucesso. Por outro lado, os processos mal concebidos são um caminho para o fracasso. Processos pobres são muitas vezes escondidos se os "heróis" da organização continuam a entregar projectos apesar dos processos. Não presuma que o sucesso do projecto é igual a bons processos, há sempre espaço para melhoria.

O que fazer: Converse com as pessoas para entender onde estão os pontos quentes e bloqueios, e atualize os processos para os remover.

 

Processo de impasse

Se um processo resulta num impasse que você deve considerar se está apto para o efeito para que foi criado.

O que fazer: Com qualquer processo, deve certificar-se que nunca alcança um ponto em que se fica incapaz de continuar.
 

Keep it Simple

Você pode ter ouvido a sigla 'Kiss' quando se trata de práticas e processos de trabalho. Ela representa, 'Keep It Simple Stupid " e enquanto eu não defenderia o uso deste com os seus colegas e clientes, você pode mantê-lo em mente ao criar novos processos ou melhorar os já existentes.

Os melhores processos são aqueles que são mantidos simples. Elas são fáceis de entender e de ter etapas e resultados claros.

O que fazer: Olhe para cada etapa de um processo e pergunte se é mesmo necessária. Ela pode ser removida? Será que ajuda a mover em direção ao objetivo? Quanto menos etapas de um processo melhor, então acho que é 'Kiss'.
 

Em resumo

Se se tornar demasiado orientado para os processos arrisca-se a perder de vista o objetivo do negócio. Certifique-se de mantem os seus processos simples, verifique-os com as pessoas que irão utilizá-los e evite processos que podem resultar acabar num impasse. Bons processos irão conduzir o seu negócio em direção aos seus objetivos, mas os processos pobres podem e irão atrasar o negócio.

Se as coisas não estão a funcionar, não culpe as pessoas, culpe os processos e tome medidas para os melhorar.

segunda-feira, outubro 07, 2013

Um princípio fundamental na gestão de Incerteza

Existe um mito popular nos projectos e, muito em especial, nos projectos de software que impede que resultados accionáveis ​​ocorram. É comum acreditar - erroneamente por sinal - que não podemos prever o futuro.

Não é o projecto que é inerentemente incerto no futuro. São os participantes do projecto que ainda têm de identificar plenamente o trabalho real que está lá fora para ser feito e está lá o tempo todo. Mesmo que o âmbito do trabalho não tenha sido totalmente percebida antes - o progresso identifica as incertezas e quantifica as acções correctivas para lidar com essas incertezas.

Isto é bastante importante para ser dito novamente. Não é o projecto que é incerto. É a nossa capacidade de ver essas incertezas se não olharmos para elas. Esta é uma diferença fundamental entre as incertezas em finanças, sociais, políticos, ou outro sistema caótico e um projecto. Há várias razões que fazem com que não possamos ver para o futuro:

  • Nós não nos podemos dar ao luxo de olhar para o futuro. Não temos tempo e dinheiro suficiente para fazer o trabalho necessário para revelar as possibilidades futuras. Significa geralmente que nós vamos descobrir isso quando chegarmos lá. Derrapagens de custos e atrasos não são incorporadas no plano. Ou vamos ter que rever o âmbito do projecto quando corremos contra o tempo e o dinheiro.
  • Não sabemos onde olhar para ver as incertezas. Nós não temos as competências certas, experiência ou capacidade para saber para onde olhar. A solução mais simples é a de ir buscar alguém que o sabe fazer. Vê-los a trabalhar e aprender.
  • Não queremos realmente saber as incertezas do futuro. Você não consegue lidar com a verdade (You can't handle the truth!).  É muito mais comum do que se imagina. Saber o custo e o cronograma do projecto até um nível de confiança de 80% pode fazer com que o projecto não se inicie ou seja cancelado.
  • Não queremos simplesmente fazer o trabalho necessário para olhar para o futuro para ver onde o problema se apresenta, onde o custo irá ocorrer, onde podem ocorrer atrasos. Esta é uma abordagem daqueles que normalmente não são responsáveis pelo custo e do cronograma do projecto. Eles não conseguem ligar os pontos entre o trabalho e o dinheiro de outras pessoas. Isso geralmente é uma visão bottom-up do mundo.

Os problemas acontecem em projectos, essa é a natureza de todos os projectos. Gerir as questões que vão acontecer no futuro é uma factor crítico do . Não gerir isto significa que estas questões vão dominar os resultados do seu trabalho.

Reblogued from Herding Cats by Glen B. Alleman

segunda-feira, julho 22, 2013

Gerir trabalhadores remotos

Por Ten Six traduzido e adaptado

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

Há alguns cuidados que os gestores devem ter como:

Garantir que todos têm acesso às mesmas ferramentas

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

Inclua os trabalhadores remotos nos eventos sociais

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

Estabeleça objectivos claros

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

Forme toda a equipa

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

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

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

Mantenha-se organizado

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

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

quarta-feira, maio 08, 2013

Técnicas de Identificação de Actividades

A Work Breakdown Structure (WBS) é uma ferramenta de categorização do trabalho usada para planear, gerir, executar e reportar um projecto. Desta forma, a WBS deverá ser uma referência principal durante o processo de planeamento e especialmente para a identificação das actividades. Cada actividade deve ter unicamente uma designação de WBS.

Em projectos de curta duração ou complexos, é uma boa prática identificar e incluir no processo de planeamento e workshops conforme o caso, o membro da equipe de projecto específico que será responsável pela execução de cada actividade e será responsável pela sua realização. Esta abordagem de atribuições pode ser difícil para projectos de longa duração. Por conseguinte, é também uma prática recomendada definir completamente e documentar a base da actividade para garantir que a pessoa responsável pelo seu futuro desempenho compreende o âmbito da actividade.

Uma actividade é composta dos seguintes atributos essenciais que são derivados da WBS e fontes de apoio listados acima.

  • Um identificador único Alfanumérico. Deve ser capaz de fornecer uma identificação "inteligente" da actividade em que os identificadores únicos de actividade são organizadas de forma sistemática para se relacionarem com vários agrupamentos de actividades do cronograma. Essa inteligência permite uma melhor classificação e facilidade de comunicação.
  • Um período de duração inicial de trabalho. Este deve reflectir o âmbito de aplicação descrito no título da actividade.
  • A atribuição de um calendário. Deve ser tomada decisão se uma actividade deve ser agendada em um determinado calendário de trabalho. A necessidade de vários calendários para o projecto deve ser revista, pois o uso de vários calendários pode afectar o cálculo do float de cada actividade (por exemplo, caminho de float descontínuo) e a equipe deve estar de acordo sobre a escolha do calendário.
  • Um título descritivo do âmbito do trabalho previsto. Deve ser clara e sucinta, sem ser vaga e / ou ambígua.

A sequência preliminar de ligações lógicas liga a actividade a um antecessor e sucessor de acordo com o plano de execução do projecto. É importante que a lógica inicial reflectir uma sequência prudente e prática para o desempenho do trabalho. A partir de tal sequência inicial será facilitada a determinação posterior das sequências alternadas que podem encurtar o tempo de conclusão e o custo.

A descrição da actividade e a duração inicial da actividade deve comunicar de forma inequívoca o âmbito do trabalho. Isto reduz a confusão entre as partes interessadas e facilita as revisões da lógica, a medição de progresso da actividade para pagamento, previsões e outras tarefas. Incluindo uma entrega ou quantificador na descrição da actividade, tal como a dimensão, a quantidade ou a demarcação física é geralmente uma boa maneira de se comunicar o âmbito dessa actividade (as percentagens não são um bom quantificador). A intenção de um quantificador não é duplicar as quantidades orçamentadas que estão em outros lugares da ferramenta de controlo, mas para tornar o âmbito de actividade tão auto-evidente quanto possível.

As descrições das actividades devem ser consistentes com o nível de esforço e a duração necessários para a conclusão dessa actividade.

Deve ser tomada uma decisão precoce pela equipe durante o processo de planeamento para determinar o nível de detalhe e o número geral de actividades apropriados para a gestão do projecto. Projectos de curta duração e de baixa complexidade, geralmente, não necessitam do mesmo nível de identificação detalhada de actividade do que projectos complexos e de longa duração. Algumas considerações na determinação de níveis adequados de detalhes incluem:

· Duração do projecto - projectos de curta duração requerem normalmente menos nível de detalhe do que um projecto de duração mais longa. Como orientação geral, as durações das actividades devem ser aproximadamente do mesmo comprimento que a frequência prevista do projecto para os relatórios de status de progresso.

· Complexidade do projecto - Projectos complexos podem ter curta duração, tais como falhas de manutenção e medidos em horas, mas ainda podem exigir um maior nível de detalhe na identificação actividade.

· Metodologia de Execução - Projectos com um alto nível de sub-contratação exigem geralmente menos detalhes do que projectos auto-realizados.

· Fase de Projecto - O nível de detalhe na identificação da actividade deve corresponder ao tipo de trabalho que está sendo realizado, e as informações disponíveis, para essa fase. Por exemplo, durante a fase conceptual a inicaçã pode ser planeada com actividades de nível sumário, enquanto a engenharia de projecto pode ser planeada em maior detalhe.

· Custo do Projecto - Geralmente, quanto maior o custo do projecto maior nível de detalhe na identificação da actividade.

· Custo e capacidade de rever adequadamente o Cronograma - O dono de um projecto não deve exigir a apresentação de um cronograma que é mais detalhado e complexo daquilo que o dono é capaz de analisar correctamente. Como submissão necessária, a programação torna-se uma notificação formal do plano do contratante e o proprietário é responsável por uma razoável compreensão dos conteúdos.

· Custo de manutenção do cronograma - Um maior nível de detalhe na identificação de actividades normalmente resulta num aumento do custo de manutenção e acompanhamento da programação. Este é um dilema importante que a equipe do projecto deve considerar em seu planeamento.

· As expectativas do cliente - O proprietário / cliente pode ter exigências específicas do cronograma que podem determinar o nível de pormenor exigido na identificação da actividade.

· Risco do Projecto – Normalmente os projectos de alto risco são planeados em detalhe para ajudar na mitigação de risco.

· Mensurável - Ao identificar as actividades a equipe deve assegurar que todas as actividades podem ser facilmente medidas e controladas de forma única.

"Rolling Wave" é um planeamento de programação e método de desenvolvimento em que as actividades de curto prazo são planeadas com mais detalhes do que as actividades posteriores e a prazo. É particularmente útil para os programas de longa duração financiados por ano fiscal e não é geralmente recomendado para projectos. Como o trabalho ou programa curto prazo é executado, a equipe vai identificar as actividades detalhadas subsequentes que são necessários e substituir as actividades sumárias em "espaços reservados" correspondentes. O planeamento em "Rolling Wave" é uma técnica de planeamento de actividades reservada a programadores experientes que trabalham em empreendimentos complexos e de longo prazo. O programador inexperiente deve procurar a orientação da equipe de gestão de projectos antes de utilizar esta técnica.

Milestones são eventos únicos sem duração que marcam pontos importantes na execução do projecto. Como parte do processo de planeamento, estas metas devem ser identificados pela equipe do projecto, e incluídas na lista de actividades.

As Actividades sumárias são um grupo especial de actividades que adquirem a duração do período de tempo entre o antecessor e sucessor de actividade de resumo. Eles só devem ser usados ​​para resumir uma série encadeada de actividades que ocorrem entre o período do primeiro antecessor e sucessor das últimas actividades. As Actividades Sumárias são úteis para apresentar um maior nível de gráficos e relatórios tabulares de dados discretos.

Durante o processo de planeamento de actividades é fundamental que todos os pressupostos de desempenho de trabalho estejam claramente documentados. Além disso, as interpretações de âmbito do projecto escopo, as suas inclusões e exclusões e outras informações de base devem ser documentadas. Esta documentação vai ajudar a reduzir o risco de erro ou má aplicação no desenvolvimento do cronograma subsequente. Eventualmente, estes pressupostos vão se tornar uma parte do documento escrito base da programação.

Na conclusão das sessões de planeamento do cronograma, a lista de actividades deve ser revista para ser completa. Essa revisão deve incluir:

  • A lista de atividades do cronograma inclui o âmbito total do projecto?
  • Estão incluídos todas as esperas para as aquisições grandes e de longo prazo?
  • O nível de detalhe é o adequado para a fase de projecto, sua complexidade e risco?
  • Podem ser sumarizadas todas as actividades de acordo com a WBS?
  • Será que cada actividade tem uma única pessoa responsável e confiável?
  • Foram consultados especialistas para necessidades específicas?
  • Foram consideradas a história de projectos passados e as lições aprendidas?
  • Pode medida e identificada com exclusividade cada actividade?
  • Foram incluídos todos os marcos importantes do projecto?
  • Foram documentados todos os pressupostos da actividade?
  • Foram considerados os constrangimentos factores externos?

Retirado de

AACE International Recommended Practice No. 23R-02
IDENTIFICATION OF ACTIVITIES

segunda-feira, maio 06, 2013

7 erros de planeamento a evitar

por Ten Six

O agendamento é uma das coisas mais importantes com que uma ferramenta de gestão de projectos pode ajudar. Mas, por boa que seja a ferramenta, é tão útil quanto os dados inseridos na mesma. Cronogramas de projectos complexos fatalmente mudam ao longo do caminho - como disse o Marechal alemão Helmuth von Moltke, nenhum plano sobrevive ao contacto com o inimigo.

No entanto, você pode dar a seu projecto uma oportunnidade de sucesso, evitando estes 7 erros de programação.

1. Deixar de assinalar as actividades concluídas

Todos os gestores de projecto que conheço gostam de assinalar como concluídas as tarefas duma lista. Tendo em conta isto não seria muito provável ter gestores de projecto a esquecer de marcar as tarefas concluídas como realmente completadas. Infelizmente, é um erro comum. Isso só mostra que o gestor de projecto não actualiza o status do projecto actual, e não está próximo das equipes que fazem o trabalho. Receba as actualizações regulares dos membros da equipe e certifique-se que você sabe exactamente o que foi concluído a qualquer momento.

2. Deixar de actualizar o progresso das actividades em curso

A falta de controlo do status não afecta apenas as tarefas concluídas. O progresso deve também ser monitorado para as actividades que estão em curso. Isso permitirá que veja o que está a ser trabalhado.

3. Não decompor os resultados de alto nível

Os planos só são úteis quando as actividades incluídas são de um nível de granularidade que faz sentido para acompanhar. Actividades como "Organizar conferência 'são difíceis de controlar, porque elas são compostas de uma série de resultados menores, como' contratar local ',' convidar conferencistas" e "Definir a reserva de website”. Decompor as grandes actividades em tarefas menores. A regra de ouro é parar quando as durações das actividades são de cerca de uma semana.

4. Dependências que estão em falta

O planeamento torna-se menos preciso quando as dependências estão em falta. Não será capaz de ver o que tem que acontecer primeiro, ou qual o esforço a jusante que depende de actividades que devem ser concluídas. Reúna-se com a equipe e analise onde estão as dependências e, em seguida, certifique-se de que sua programação reflecte com precisão todos elas. Não julgue que sozinho é capaz de fazer isso, recorra à ajuda de outros.

5. Falhar a ajustar o esforço de previsão

Quando as actividades na programação ficam atrasadas, a visão optimista é a esperar que a equipe consiga recuperar. Com toda a nossa experiência na Ten Six, sabemos que isso acontece, de facto, muito raramente. As actividades atrasadas normalmente ficam mais atrasadas. Se você sabe que algo está atrasado porque está levando mais tempo do que o planeado, ajuste o esforço restante para essa actividade em conformidade. Por exemplo, se a duração da tarefa é de quatro semanas, e concluiu o esforço de uma semana, mas isso tomou duas semanas de tempo decorrido, você sabe que está a trabalhar a cerca de metade da velocidade que você precisa planear mais quatro semanas para esta actividade.

6. Não planear para a disponibilidade dos recursos

Mesmo o melhor plano do mundo deixará de ser exacto no momento em que as pessoas estão indisponíveis para trabalhar nas suas actividades. Plano com previsão, especialmente com os recursos a tempo parcial. Você deve ter como objectivo dar às pessoas (e seus responsáveis) aviso sobre quando eles devem começar a trabalhar nas actividades, e lembre-se de os manter actualizados até à data pois se as coisas mudam, porque você está atrasado ou por ter ganho a algum tempo poderá ter de necessitar das suas competências mais tarde ou mais cedo.

7. Falhar no ajuste da programação às mudanças no âmbito

Tem de haver uma ligação entre o processo de gestão de mudança do projecto e o cronograma. A maioria das mudanças terão algum impacto no cronograma, seja através de adicionar ou remover algo do âmbito do projecto ou alterar por algum motivo datas de marcos importantes. Certifique-se de que seu projecto integra o processo de gestão da mudança e o processo de planeamento, de modo que você possa implementar imediatamente as mudanças na programação, como resultado de mudanças no âmbito. Esta é também uma boa forma de garantir que toda a gente sabe que a mudança foi implementada - às vezes os membros da equipe do projecto na obra não estão perto dos principais processos e podem não estar cientes de que algo mudou.

A boa programação leva tempo e compromisso e o esforço para se manter a par de tudo, o tempo todo. É um grande trabalho, especialmente em projectos complexos, mas se você mantiver o foco você pode evitar esses 7 erros de programação. Helmuth von Moltke ficaria orgulhoso de si.

sexta-feira, abril 19, 2013

O que é Planeamento?

Muitas vezes temos intervindo em público sobre o planeamento de projectos e a gestão de projecto e confrontamo-nos com a constante dificuldade que as pessoas têm de compreender o que é efectivamente planeamento. Fomos recolher um importante auxílio a um documento da American Association of Cost Engineers. Identificamos o que é planeamento e depois distinguimos entre o Plano do Projecto e o desenvolvimento do cronograma.

O Planeamento de projecto consiste em:

· Identificar os stakeholders do projecto e os seus papéis, responsabilidades bem como o seu efeito sobre o processo de planeamento e de programação.

· Identificar os requisitos de contrato, incluindo os métodos de entrega de projectos sob os termos do contrato. O método de entrega do contrato vai determinar a extensão do esforço de planeamento pela equipa do projecto.

· Identificar as restrições e variáveis ​​que permitirão que a equipa do projecto possa iniciar o processo de planeamento.

· Estabelecimento de um processo de planeamento para determinar o âmbito do trabalho, requisitos do cliente, hierarquia do cronograma, divisão de responsabilidades revisão do plano do projecto e requisitos de aprovação e distribuição.

· Identificar as principais actividades de trabalho (fases) e resultados (metas) e a sequência adequada em que devem ser realizadas.

· Estabelecer um plano agendado de tempo integrado e faseado para atingir a conclusão do projecto, conforme requerido.

· Identificação da coordenação de gestão do projecto necessária para estabelecer áreas de custo / programação para a melhor definição do âmbito do trabalho.

· Desenvolvimento metodologias de gestão de projecto não-relacionadas com a programação, tais como planeamento logístico, incluindo, mas não limitados a: plano de acesso ao site, planos de carga pesada, colocação de guindastes, com planos longos de aquisição de materiais / equipamentos, planeamento de material / equipamento fornecido pelo proprietário e outros planos específicos para diferentes usos.

 

Desenho do plano e Desenvolvimento do Cronograma

Planeamento e programação são processos distintamente diferentes, mas relacionados para projectos de construção de capital. Desenho do plano e desenvolvimento do cronograma geralmente exigem um conjunto diferente de habilidades e conhecimentos.

Planeamento consiste em planear o trabalho, os recursos, e o custo estimado ao longo do tempo para completar o âmbito do trabalho definido nas fases iniciais do projecto. Programação do projecto inclui a identificação de muitos elementos que estão associados com o âmbito de trabalho que é desenvolvido em pacotes de trabalho, sequenciados em fases e em seguida as actividades específicas. Os meios, métodos e recursos têm processos de planeamento iterativo como o plano de projecto é desenvolvido antes da fase de execução do projecto. Esta programação continua a evoluir durante a vida do projecto e coloca a ênfase na experiência e nos conhecimentos adquiridos com os sucessos e fracassos de projectos anteriores.

O propósito do planeamento por uma equipa de gestão de projecto é estabelecer um curso de acção aceitável ("Plano") para realizar o âmbito de trabalho de um projecto de uma maneira eficiente e coordenada com base numa revisão dos requisitos de projecto e responsabilidades. Incluído neste esforço de planeamento está a identificação das partes interessadas, os requisitos de contrato, e o método de entrega do projecto que são elementos-chave no esforço de planeamento inicial.

O objectivo da programação por uma equipe de gestão de projecto é desenvolver uma ferramenta de gestão de tempo em fases que vai ajudar a implementar o plano aprovado e orientar o projecto para os resultados desejados utilizando os resultados do processo de planeamento. O planeamento deve preceder o esforço de programação e, embora possa tornar-se menos formal em fases posteriores do projecto, o planeamento é um processo contínuo que nunca pára até que o projecto esteja concluído. O cronograma do projecto é detalhado durante a fase de desenvolvimento do cronograma do projecto. Há uma transição relativamente suave de planeamento do projecto de cronograma de desenvolvimento, enquanto o documento do plano do projecto é finalizado e revisto pelas partes interessadas apropriadas.

(Extraído de 39R-06: Project Planning – As Applied in Engineering and Construction for Capital Projects, da AACE® International)

terça-feira, março 19, 2013

O livro na Amazon

Planear projectos de grande dimensão com  Oracle Primavera P6

Gestão com Oracle Primavera P6 (Portuguese Edition)A primeira edição do Gestão com Oracle Primavera P6 para projectos de grande dimensão já está publicada na Amazon em formato Kindle.

Pode comprar aqui Gestão com Oracle Primavera P6.

Estamos a realizar actualizações mensais que depois podem ser obtidas pelos leitores.

Não tem Kindle?

Não importa? Pode ler descarregando o leitor do Kindle para o seu computador. Este está disponível em:

Free Reading Apps

Ou pode ler no seu browser em Read.Amazon.com

Estou a finalizar a versão inglesa.

Book Description

Publication Date: January 31, 2013

O presente volume tem por objectivo apresentar e documentar aos gestores de projecto que, por obrigação profissional, terão de usar o Oracle Primavera P6 como ferramenta de controlo de projecto, um processo geral mas ilustrado para enfrentarem as suas responsabilidades. Este processo decorre das boas práticas que fomos recolhendo nos projectos que acompanhámos e para o qual fornecemos as ferramentas de software e muitas vezes também serviços.


Product Details
  • File Size: 1820 KB
  • Print Length: 124 pages
  • Publisher: Enfase, Lda; Primeira edition (January 31, 2013)
  • Sold by: Amazon Digital Services, Inc.
  • Language: Portuguese
  • ASIN: B00B9BGOZO
  • Lending: Not Enabled