Iniciação do Projeto

Muitas decisões são tomadas durante a vida de um projeto, mas a decisão que como maior impacto de todas é a primeira; esta é a decisão de executar o projeto. Vamos analisar a fase de iniciação do projeto que decorre antes dessa primeira decisão.

Para a primeira decisão devemos realizar a análise cuidadosa dos benefícios do projeto potencial, as necessidades de recursos, os custos e o peso do portfólio organizacional e congruência estratégica e tudo ponderado então proceder à decisão de iniciar o projeto. Como os esforços de iniciação do projeto normalmente começam informalmente, muitas vezes a decisão e esta ponderação não é executada de forma tão rigorosa como necessário.

A análise de potencial de projeto, normalmente é embalada numa proposta formal de iniciação do projeto. A proposta, de facto, é a saída ou resultado do processo de iniciação do projeto. Importa ser claro. O sucesso da decisão de "go/no-go ' deve basear-se numa análise disciplinada e completa que culmina na proposta de iniciação do projeto. E, sim, como mencionado, o projeto potencial deve ser considerado à luz de outros projetos da organização e da mais abrangente estratégia. Embora os projetos possam variar em tamanho ou complexidade existem princípios comuns que devem ser empregues antes de decidir sobre cada implementação do projeto.

Neste artigo descrevo alguns princípios fundamentais para apoiar a decisão de aprovação de lançamento de iniciação do projeto.

Input dos Stakeholders

É essencial manter a comunicação das partes interessadas durante todo o ciclo de vida do projeto, mas o envolvimento das partes interessadas é especialmente importante na fase de iniciação do projeto. A fim de incluir e envolver as partes interessadas certas deve considerar o seguinte na sua pesquisa:

• Todas as pessoas que podem interagir com o produto ou serviço. Isto inclui não só o utilizador final, mas também os fornecedores e providers da manutenção. Entenda o problema ou oportunidade a partir da perspetiva em que cada um é afetado diretamente.
• Mude os defensores e opositores. Alguns defensores incentivam a mudança, enquanto outros procuram manter o status quo. Quais são os motivos por trás de ambos os lados do argumento de mudança?
• O cliente é definitivamente impactado pelo projeto e a importância de ouvir o input do cliente tem de ser sempre enfatizada.
• Estado e administração local. Sim, as leis e regulamentos dos órgãos do governo tornam-nos numa das partes interessadas.
• ·         Cultura e valores. O apoio ou desaprovação podem estar profundamente enraizados em crenças fundamentais, que podem ultrapassar os benefícios propostos. 

O propósito de mencionar este processo de estudo das partes interessadas não é encorajá-lo a aprofundar o mundo das partes interessadas, mas antes reconhecer a importância, desde o início, de uma análise exaustiva das partes interessadas para o conhecimento do projeto. O valor do conhecimento das partes interessadas é o de proporcionar a deteção precoce de requisitos e restrições. Quanto mais cedo os conhecermos, mais baratos são de gerir.

Clarificação dos Problemas

Não compreender verdadeiramente qual o problema que é preciso resolver é um erro muito comum. Então, gastar tempo a definir o problema, e empregar a "análise de intervalos", o que explica o problema como a diferença entre o estado atual e o ideal.

Compreender que o estado ideal estabelece um quadro para a avaliação de alternativas. Disciplinando-nos para definir adequadamente o problema proporciona soluções mais plausíveis e, possivelmente, melhores. Se realmente entender o problema então será capaz de desenvolver uma melhor gama de soluções viáveis.

Analise diversas alternativas

Se identificou completamente o problema, então terá várias soluções para explorar. E considerar ainda outras abordagens alternativas inspira outras novas ideias para resolver o problema. O objetivo depois é classificar estas soluções de acordo com seus custos e benefícios.

O desafio na análise de alternativas é que normalmente comparamos maçãs e laranjas: opções com vantagens diferentes e desvantagens. Quantificar os custos e benefícios permite ver as diferenças entre as alternativas. Os benefícios são tangíveis ou intangíveis. Os benefícios tangíveis são mensuráveis. Descrever e quantificar cada benefício tangível, e listar os seus pressupostos. Embora os benefícios intangíveis sejam difíceis de medir mesmo assim são importantes. Mais uma vez, deve descrever o benefício, os pressupostos e a probabilidade de sucesso. Além disso, deve considerar e comparar os recursos necessários para cada abordagem.

Encontrar formas de quantificar e comparar custos e benefícios permite perceber porque perseguir um menor custo e uma opção de menor alcance é melhor do que uma opção mais cara que tem todo o âmbito de aplicação, ou seja, "todas as funcionalidades”. Será que o ótimo é mesmo inimigo do bom?

Considere o portfólio e a estratégia

Chegado ao ponto em que não só definiu o seu problema, mas tem também uma solução proposta – o seu projeto. Antes da empresa mergulhar na execução do projeto devemos querer considerar se o projeto corresponde aos critérios de seleção. A maioria das empresas categorizam os projetos dentro de uma carteira de projetos. Os fatores principais ou benefícios dos projetos estão geralmente nas seguintes categorias:

• Conformidade/regulação. Os requisitos do projeto são orientados para a necessidade de certa lei ou regulação.
• Eficiência/redução de custo. O propósito é diminuir os custos operacionais.
• Aumento do rendimento. Estes projetos tendem a ser de risco elevado, mas tem resultados muito desejáveis e favoráveis.

As empresas alocarão recursos e o risco entre estas categorias tal como um investidor do mercado de ações distribui dinheiro entre os investimentos de renda e de capital fixo. O objetivo do investidor é diversificar os investimentos para reduzir riscos e aumentar os ganhos potenciais. As empresas diversificam projetos entre as categorias de projeto para minimizar o risco e obter alavancagem para o ganho máximo. Além de classificar o projeto, indicar como o projeto se alinha com outros projetos da empresa e a estratégia global da empresa.

Sumário

Os pré-requisitos da decisão de início do projeto incluem, com a consulta a uma ampla variedade de partes interessadas, esclarecer o problema, analisar alternativas, e considerar portfólio da empresa e estratégia. O resultado desses esforços de iniciação do projeto será uma proposta de iniciação do projeto que é adequada para o processo de seleção da empresa.

A decisão de "go no-go 'decisão pode ser parte de um processo de gestão de portfólio de projeto ou uma decisão pessoal de um executivo. É importante a execução de trabalho base de apoio a uma decisão de iniciação bem sucedida. Mais uma vez, a decisão de executar o projeto tem o maior impacto. Pode não ter a autoridade para tomar essa decisão, mas pode estabelecer a base para uma decisão de compromisso bem sucedida. E às vezes a melhor decisão é a de não prosseguir o projeto.

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.

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

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.

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

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.

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!».

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.

O livro na Amazon

Planear projectos de grande dimensão com  Oracle Primavera P6

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

Como decidir com PRINCE2

Falamos muitas vezes de Gestão de Projecto, de boas e melhores práticas de gestão, mas devemos também salientar alguns aspectos do que distinguem essas práticas umas das outras. Abordamos alguns aspectos do processo de decisão de direcção de topo em que O PRINCE2 se destaca. O método exige uma ligação bem estruturada e definida entre o gestor de projecto e a direcção – o Board de projecto, e uma abordagem muito estreita entre a definição de etapas e a execução do projecto sob a direcção do Board.

O que torna o PRINCE2 um método com tanto sucesso na gestão de projectos (quando utilizado devidamente) é porque compreende que todos os projectos, tal como as viagens, são geridos melhor em etapas. E, embora seja o Board do Projecto que decide num conjunto de etapas, os gestores de projecto têm de entender o processo para que possam realizar o que o Board e o projecto necessitam. Como?

1. Um passo de cada vez. Tal como os seus planos de viagem podem dar em erro se tentar fazer tudo de uma só vez, também no seu projecto irá abrandar ou parar se tentar fazer tudo numa só etapa. O Board junta unidades de trabalho de razoável dimensão que se encaixam naturalmente.
2. Dinheiro, grana, cacau… Podem chamar-lhe o que quiserem, este é um dos controlos chave usados pelo Board de Projecto. Assim enquanto destina e reserva o dinheiro para todo o projecto, poderá provavelmente só autorizar dinheiro para um projecto de cada vez. Se o Board determina que 5 milhões é o máximo que irá autorizar para uma etapa e uma etapa particular custaria 8 milhões, então será requerido dividir a etapa em duas mais pequenas.
3. Tick, Tack… Poderá ser bom para si usar uma duração de 6 meses para concluir uma etapa, mas o Board poderá querer saber como correm as coisas cada três meses.
4. Especular com o futuro. Se a etapa do projecto é de alto risco, como uma viagem por território perigoso, pode apostar que o Board do projecto estará nervoso. O mais provável resultado será que o projecto seja dividido em tantsos as etapas quanto as necessárias para reduzir o risco.
5. Você. Os projectos são acerca de pessoas e você é a coisa mais importante que existe num projecto. Se você é um gestor de uma equipa de Formula 1 então o Board confia-lhe etapas mais longas e dispendiosas porque sabe que irá entregar. Se você estiver na Formula então não irá culpá-los por quererem estar mais perto do desenvolvimento do projecto. Isto até pode funcionar em seu benefício já que poderá controlar com eles, de tempo a tempo, quando não estiver seguro de alguma coisa.

Há muitos mais factores para ajudar à decisão do Board de Projecto durante as etapas do projecto porque com PRINCE2 fazer as coisas não é fazer cruzes numa lista.

Luis Quintino

Estabelecer na empresa a função de Gestão de Projecto

Na maioria das organizações é muito difícil estabelecer a gestão de projecto, porque os gestores têm medo de perder a autoridade e o controlo sobre os recursos que lhes estão atribuídos. Os trabalhadores, pelo seu lado, têm medo de serem tornados responsáveis pela realização de novos conjuntos de requisitos.

As iniciativas descoordenadas de estruturação de boas práticas e os projectos organizados mas sem consistência e sem continuação na companhia não dão frutos e os seus resultados não são difundidos pela companhia. É necessário definir uma estratégia consistente e adequada para que o objectivo de uso da gestão de projecto na companhia seja alcançado.

A realidade é que em muitas companhias fala-se da gestão de projecto, mas quando se trata de fazer um esforço para implementar processos tudo é realizado de forma anárquica e inconsistente. Exactamente o contrário do que a gestão de projecto exige.
 

Estratégia de Gestão de Projecto

A solução exige o posicionamento ao mais alto nível dentro de uma organização da função de gestão de projecto pra oferecer a medida de autonomia necessária para alargar a autoridade por toda a companhia da gestão de projecto enquanto salienta a substância do valor e importância da função aos olhos da gestão executiva.

O primeiro passo que é exigido para atingir o objectivo de estabelecimento da disciplina de gestão de projecto por toda a companhia é a criação da função de negócio em condições em que possua a autoridade e a responsabilidade para realizar este trabalho.

O segundo passo é definir um grupo com essa responsabilidade para estabelecer o sistema e pô-lo a funcionar. Este pode ser denominado Centro de Excelência de Gestão de Projecto ou Project management Office (PMO). Estabelecer a gestão de projecto como uma função de negócio não deve ser visto como uma panaceia ou solução de remediação, mas antes como um esforço de fundação e construção de longo prazo.

O terceiro passo é usar com efectividade, portanto, de forma consistente, as técnicas de gestão de projecto o que é o elemento crítico para atingir melhorias nestas áreas. Algumas companhias vêem a gestão de projecto como a arma fundamental no seu arsenal para incrementar a satisfação dos clientes e bater a concorrência.
 

Exiegências do Mercado actual

Competir globalmente, aumentar a quota de mercado, reduzir custos e melhorar os lucros – tudo enquanto produzimos melhores produtos e serviços mais rapidamente através do uso de soluções de alta tecnologia – são só s algumas das razões pelas quais a maioria das organizações procura melhores formas de melhorar o seu tempo para o mercado, o seu custo para o mercado e a sua qualidade para o mercado.

A companhia como um todo deve reconhecer e adoptar novas atitudes que adoptam as melhores práticas da gestão de projecto como a forma normal de trabalhar. Isto permitir-lhes-á usar a poderosa força desta nova arma competitiva para o sucesso na batalha do crescimento continuado do negócio e em muitos casos para a sobrevivência no mercado global altamente competitivo dos nossos dias.

Planear projectos no ambiente de Help Desk de TI

Tradução de post de Anna Halstead, PMP

Os serviços de Help Desk, no domínio do Suporte de TI, têm muitas vezes de proceder a preparações para fornecer suporte para uma nova ferramenta, aplicação, tecnologia ou produto que serão implementados para os seus utilizadores finais. Embora este tipo de projectos sejam normalmente pequenos e não complexos, todos os projectos de help desk devem ter um planeamento adequado e seguir uma estrutura de projecto, deforma a manter a satisfação do cliente e garantir que quaisquer mudanças no ambiente suportado, não tem um impacto negativo no serviço que o help desk fornece. Afinal, um dos propósitos chave do help desk na sua operação diária é garantir a satisfação do cliente através do fornecimento consistente do serviço acordado. Isto poderá estar em risco quando o suporte para uma nova tecnologia, ferramenta, aplicação ou produto é introduzido e o cliente fica insatisfeito com o serviço.

Estamos a falar de que tipo de projectos?

O projecto pode ser, por exemplo, entrada em produção uma aplicação de negócio para a companhia, migração de utilizadores finais para um cliente de email diferente ou actualização de uma nova versão de uma aplicação existente ou de uma tecnologia já em uso. Se forem estes os casos, as possibilidades são de que o suporte do Help Desk é só uma parte de um projecto maior e trans-departamental. Muitas vezes é onde as questões podem começar se o Gestor deste Projecto não está totalmente consciente da função que o Help Desk irá desempenhar ou assumir que não é necessário planeamento. Nestas circunstâncias, a prontidão do Help Desk pode ser sobrestimada, o que será extremamente frustrante para o pessoal envolvido e para os clientes. O gestor de projecto do Help Desk deverá assegurar-se que a globalidade da organização de TI está consciente doq eu faz ocall center e a função que desempenha quando fornece o suporte ao utilizador final.

Temos de fazer as perguntas certas desde o início. Para avaliar o âmbito e o impacto que o projecto vai ter no Help Desk e nos utilizadores finais.

Duas razões do fracasso dos projectos

As histórias de fracassos espectaculares abundam, mas nem sempre são vistas como aquilo que são – exemplos. Já ouvimos falar dum projecto que tinha 150.000 euros de orçamento inicial e só é fechado quando ultrapassou já 1.000.000 de euros. Ou um projecto para um novo sistema que devia ser entregue em Julho e que é finalmente posto em produção em Setembro, mas dois anos depois. Qual será a razão que persegue os projectos e os conduz a estes fracassos.

O culpado mais apontado, por muitos, é a deficiente estimação. Há uma anedota o comum que afirma que uma pessoa com perfil técnico tem muita dificuldade em estimar o custo do almoço, mesmo quando dispõe de uma ementa. Mas isto é, claro, um mito.

Há pessoas com baixas capacidades de estimação, mas mesmo quando as estimativas falham por cem por cento, o custo total não poderá ultrapassar o dobro do inicial. Se as contas estão bem-feitas! Isto não é o desejável, mas nada disto é comparável com as ultrapassagens que todos conhecemos em projectos que parecia serem todos muito sérios e com horizontes bem definidos. Lamentavelmente, na maioria deles estamos envolvidos porque de alguma forma estaremos envolvidos no pagamento de alguma coisa, já que a maioria esmagadora destes são projectos com dinheiros públicos.

Mas a má estimação não parece ser a justificação para desvios de 500 e mais por cento. De facto, muitas pessoas experientes conseguem estimar razoavelmente bem, e, na onda de um projecto grande, o optimismo de alguns estimadores equilibra-se com o pessimismo de outros. Embora existam muitas outras razões recorrentes para a falha dos projectos há duas que se salientam como principais e primárias: as alterações de âmbito e o planeamento fraco do projecto.

As alterações de âmbito são provavelmente a causa maior para o fracasso dos projectos. O problema com as alterações de âmbito não é somente porque aumentam o custo, mas porque adicionam o custo fora da proporção correspondente ao esforço aparente. Por exemplo, um projecto estimado a 20 milhões cresce até um projecto que, se tivesse sido planeado dessa forma do início, seria estimado em 40 milhões. Somos tentados a acreditar que o custo final do projecto será à volta de 40 milhões, mas muitas vezes será perto dos 80 ou 90 milhões, porque as alterações do âmbito perturbam o planeamento e o desenvolvimento do que estava já concluído, isso implica re-trabalho e , se o processo for suficientemente longo, podem comprometer a estrutura do projecto como se quisesse adicionar 5 andares a um prédio planeado para 10.

As alterações de âmbito são um problema por duas ordens de razões. (1) Quer o projecto não teve o seu âmbito definido desde o início ou o gestor de projecto falhou na gestão efectiva dos pedidos de alteração do âmbito. As alterações de âmbito são inevitáveis e não são necessariamente más. Só se tornam perigosas quando não são devidamente geridas, isto é, quando não são adequadamente definidas, avaliadas, acompanhadas e geridas.

A segunda causa de maior preocupação e causadora de fracasso dos projectos é o planeamento pobre e, em particular, a desconsideração das actividades de projecto durante o planeamento. Estas actividades não fazem parte das estimativas, elas não surgem no plano e não parece que tenham efeito no plano. Mas quando são necessárias podem provocar o caos. Por exemplo, um projecto em que é necessário realizar a formação de um grupo de utilizadores, mas que falha na definição e realização de uma actividade para criar os materiais de formação, irá ser a base de atrasos logo no momento em queo teria a possibilidade de realizar os benefícios.

Os projectos não têm de falhar! Quando um gestor de projecto experiente e as suas equipas tratam de forma séria o planeamento e a gestão das mudanças do âmbito os projectos geralmente cumprem com sucesso. Se quer trabalhar sossegadamente em projectos de sucesso e deixar os catastróficos para outros, aprenda a controlar estas partes essenciais da gestão dos projectos.

Até que ponto confia na avaliação do tempo e custo real versus o planeado?

Com a agenda das companhias dominada pelas questões de custo e eficiência foi criado um ambiente operacional constrangido em que a capacidade de comparar e contrastar o planeado relativamente ao real em tempo e custos oferece uma maior visibilidade e um controlo mais apertado da performance, determinante para a informada tomada de decisões.

A capacidade para planear com efectividade é crucial, mas poder alocar o tempo e o custo (dos recursos) com absoluta confiança em que serão alcançadas as metas financeiras e de projecto, será muito difícil se as ferramentas de planeamento e os sistemas de registo do trabalho forem usados de forma isolada como é típico nas companhias.

Os sistemas de Timesheets fornecem uma visão adequada e exacta do que deve ser facturado no final de cada semana ou mês, tornando relativamente directo calcular o custo real de atribuir recursos ao projecto e o rendimento que está a ser gerado como resultado. Contudo, se estes cálculos não forem comparados com regularidade relativamente ao tempo e recursos alocados originalmente ao projecto, não haverá forma de avaliar se estamos a trabalhar tão eficientemente como podíamos.

De forma similar, também sem mecanismos formais de reporting em posição que permitam que a gestão possa comparar regularmente o tempo planeado e o custo relativamente ao real, para determinar a exactidão do planeamento realizado não é possível ter dados rigorosos. Esta situação cria incerteza em temos de rendimentos previstos e impactos na capacidade de realocar os recursos e responder com rapidez aos picos de actividade em projecto, ou a impossibilidade de fornecer ao cliente estimativas baseadas na performance histórica quantificada.

Avaliar o níveis de variância

Planear os recursos significa avaliar os requisites destes relativamente às actividades planeadas. O que falta muitas vezes é a visibilidade necessária sobre a disponibilidade dos recursos, o que leva em muitas companhias, quer da construção como da energia, a utilizar recursos genéricos em vez de mapear o seu uso às pessoas, de acordo com as suas competências.

A capacidade de planear a alocação de recursos e prever com clareza o orçamento requerido e o tempo de execução, depende largamente do conhecimento anterior e da experiência da companhia. Muitas vezes os dados históricos não são mantidos e os factores externos parecem determinar que os projectos estejam sujeitos a mudança desde o início. Assim, só a recolha de dados de execução pode oferecer uma verificação da realidade com que o projecto foi orçamentado e do custo do projecto, o que determina o rendimento obtido pela realização de resultados para o cliente.

A variância significa que, a partir desta recolha regular de dados, é possível comparar o planeado relativamente ao executado. Uma variância negativa ocorre quando os custos reais do projecto excedem os custos orçamentados, enquanto uma variância positiva significa que o trabalho foi realizado abaixo do orçamentado.

A variância negativa resulta em ultrapassagens de custos, margem e rendimento reduzidos. Para não esquecer que as variâncias positivas não são necessariamente positivas. De facto, estas podem, por exemplo, ser um indicador de mau trabalho realizado, ou podem ainda significar, que poderia ser realizado o projecto com recursos menos dispendiosos e cumprindo as metas.

Melhorar a Performance

A análise dos níveis de variância entre o real e o planeado pode ser muito reveladora. As companhias gerem os projectos, com rigor cada vez mais aprofundado e com métodos crescentemente aperfeiçoados, e pretendem com esse esforço fazer mais com os mesmos recursos e de melhor maneira. Com isso irão obter uma margem maior e um maior rendimento.

A medida regular da performance dos projectos é a avaliação das diferenças entre os custos e o tempo planeados e os realmente incorridos e o que isso permite de detecção precoce dos problemas e questões. Só aqui se pode basear a tomada de decisões sólida e independente relativamente aos impulsos de intuição ou de avaliação com base numa qualquer «experiência».

Para isto são necessárias ferramentas que comparem os projectos, mas também nos indiquem a melhor forma de gerir a capacidade dos recursos e prever os obstáculos e problemas que são colocados pelas assumpções da realidade.

No topo das ferramentas existentes encontramos a Business Intelligence incluída nas aplicações de gestão de projecto «best of breed» da Oracle Primavera. Aqui podem ver uma demonstração do Primavera P6 Analytics.

Manter-se no caminho com exactidão

Através de um processo de melhoria contínua da efectividade geral do planeamento as companhias podem melhorar a sua performance mas também os seus níveis de serviço prestados aos seus clientes (ver post sobre as métricas das empresas) para quem os resultados estão a ser cumpridos. Quanto mais as previsões e as expectativas dos clientes são cumpridos, maior a experiência e a confiança é construída na companhia.

No clima actual em que a força de trabalho tem de encolher, tal como encolhem os orçamentos e os lucros, é essencial gerir a capacidade do uso dos recursos de forma eficiente e com utilização total. O reporting regular de tempo e custos usados e a sua comparação relativamente ao planeado é a informação essencial que permite fornecer a business intelligence para avaliar a performance entre o real e o planeado. Permite, ainda, construir uma base de dados históricos que assegura um planeamento baseado na evidência, com possibilidade de diminuição das variâncias e um maximizado aumento das margens.

Obtém-se, ainda a, visibilidade da realização dos projectos desde a estrutura organizativa até ao nível individual.

Vamos falar no próximo post na selecção das ferramentas de gestão de projecto.

O jogo do projecto – uma fábula

Agora uma fábula, já que de jogo se trata. Imagine um rei que é solteiro e quer ter um herdeiro. Ele pede a 3 membros do seu conselho para gerirem um projecto e recebe as respostas seguintes:

• O primeiro conselheiro diz que ele consegue organizar a produção de um herdeiro em 4 meses.
• O segundo conselheiro declara de 3 a 5 anos, tendo em consideração a necessidade de encontrar um cônjuge adequado, seguir protocolos complexos de noivado real, casamento e deixar a natureza realizar o seu curso.
• O terceiro afirma 9 meses.

Considerando que o rei funciona como a maioria das companhias, quem é que ele vai seguir?

A proposta do primeiro conselheiro é fisicamente impossível, quaisquer que sejam os recursos que se atribuírem à actividade. O segundo conselheiro parece ao rei demasiado cuidadoso. O terceiro conselheiro recebe o projecto, porque ele está a propor um plano agressivo mas que não é impossível. O conselheiro reconhece que o prazo não vai ser alcançado, mas pode enfrentar isso mais tarde. O rei sabe também isso, mas aposta em que o conselheiro redobrará os seus esforços para evitar o fracasso e conseguir entregar em tempo. Quatro meses e onze meses depois, nasce um príncipe.

Neste tipo de situação, a duração das actividades usada no planeamento do projecto são as mais curtas que não violam as leis da física. Os gestores do projecto fazem a venda nesta base, falham os prazos e trabalham desesperada e vigorosamente para o concluir. Como resultado de sobreviver neste jogo, são promovidos e continuam as mesmas práticas na geração seguinte.

O jogo não tem de ser jogado desta forma, mas a iniciativa deve vir de cima. Soichiro Honda estabeleceu um tom diferente no desenvolvimento da sua companhia, ao envolve-la nas corridas de motos. Quando participava numa corrida nada mais interessava a não ser que o veículo, o piloto, a equipa e os fornecimentos estavam colocados e prontos no início da corrida. Este tipo de prazos rígidos também encontramos em coisas como concertos de música, a organização de exposições em museus ou o lançamento de uma sonda espacial para voar para os planetas do sistema solar. Esta abordagem foca as equipas de projecto em realismo, avaliação das actividades e criatividade para enfrentar o inesperado.

PMO e Métricas para o Sucesso

O Project Management Office (PMO) é a estrutura orgânica / função com a capacidade de instituir numa organização uma ampla e variado conjunto de mudanças positivas. De facto, e ainda bem, em muitas organizações no mundo compreendem a co-dependência entre o executivo e o PMO e agem para estabelecer os PMOs e justificam-nos por essa mesma razão.

Infelizmente, é muitas vezes uma das partes mais incorrectamente gerida e sub-utilizada em algumas partes importantes. A Gartner, importante firma de consultoria, apresentou as conclusões de um estudo em que indica que quase metade dos PMO acaba em fracasso. A questão, então, é porque é que um número tão elevado de companhias sente que os seus PMO não realizam valor?

Há algumas respostas que devem ser exploradas, mas devido à natureza muito individual de cada PMO, é difícil ter uma lista definitiva de pontos de falha. Contudo, uma questão que atravessa quase todos os PMO tem a ver com as métricas. Demasiados PMOs não medem o seu sucesso com os adequados Indicadores Chave de Performance (KPI, como ouvimos falar com o uso do acrónimo do inglês). Devido a este fracasso, os executivos de alto nível podem com facilidade questionar o valor do PMO, particularmente o Administrador Financeiro (CFO) dirigido sempre por resultados.

O PMO, com o seu empenho em medir o processo e os protocolos, pode falhar no foco que deve ter nos KPI relevantes para o progresso global do negócio. Por efeito deste fracasso em documentar devidamente o seu sucesso, muitos PMO que antes foram produtivos estão a ser encerrados.

A lista seguinte de KPI potencialmente importantes pelos quais um PMO pode medir a sua produtividade no contexto do sucesso global da companhia. Esta lista baseia-se num estudo conduzido pelo Center for Business Practices e documentada no livro "Justifying the Value of Project Management". Julgo que estes KPI específicos são relevantes para as administrações e já provaram que melhoram as práticas de gestão de projecto.

Mas é importante, em primeiro lugar, relembrar duas coisas. Primeiro, o papel do PMO é (e será sempre) muito específico para as necessidades da Companhia em questão. Não se deve procurar aplicar estes KPI directamente. Ao contrário, eles devem adaptados para reflectirem o papel desempenhado pelo PMO. Segundo, demasiados KPI podem conduzir para uma percepção escondida da realização real do sucesso ou do fracasso.

Como se tivéssemos muitos indicadores no painel de instrumentos de um carro o que leva a que a medida seja arriscada e confusa. É sempre melhor pegar num par de KPI que se adaptam bem à companhia e focar a atenção naqueles em vez de medir uma quantidade elevada de indicadores que irão trazer resultados contraditórios.

Para que serve a Timesheet?

As Razões pelas quais os Gestores de Projecto devem Acompanhar a Duração

Nos escritórios por todo o mundo, as sextas-feiras à tarde são tempo de status e timesheets. Toda a gente desde as equipas técnicas aos gestores de projecto tem queixas acerca do sobre trabalho administrativo que implica o preenchimento das timesheets. Alguém em algum lado durante a corrente semana realizou trabalho que agora não aparece na timesheet e tem de se perguntar onde atribuir essas horas perdidas. E pode ter a certeza que alguns acreditam que todo este exercício de timesheet é exigido só por que a «gestão» não acredita que os trabalhadores consigam concluir o trabalho.

Apesar de tudo o que tem a ver com os registos de tempo, logo que as pessoas compreendem a melhor forma de o fazer de maneira a levar o menor tempo possível por semana, consegue-se geralmente obter um bom nível de adopção pelos empregados. Mas por que é isto útil? Por, pelo menos cinco razões.

Melhora a tomada de decisões

Tempo é dinheiro. Se sabe onde é que os seus empregados estão a gastar a maioria do tempo, tomará mais facilmente decisões acerca de como fazer poupanças ou em como realizar mais rápido. Por exemplo, se o tempo de viagem é consistentemente alto num projecto, pode ser apropriado analisar outras opções que estejam disponíveis em vez de ter pessoas valiosas e altamente pagas em viagem em vez de se focarem nos requisitos do seu trabalho.

Ajuda na atribuição de recursos

As ferramentas de gestão empresarial de projecto tornam fácil registar em que é que as pessoas estão a trabalhar e quais os projectos que estão no portfólio. Se pusermos os dois em conjunto verificamos que uma ferramenta empresarial pode mostrar quais os recursos que são necessários para os projectos em imediatos. Conhecer quais os requisitos do trabalho dos próximos projectos significa que se pode identificar quem estará livre para os concretizar.

Podemos até simular os recursos para definir o que poderá acontecer se se tirar alguém tirar alguém mais cedo de um projecto para realizar algum trabalho nestes projectos. A capacidade de simular com os recursos mostra as várias diferentes opções e permite seleccionar as mais apropriadas para cada situação.

Favorece a comunicação

As pessoas resmungam contra as timesheets, mas os dados que elas oferecem oferece um bom ponto de discussão. Saberá em que é que as pessoas estão a trabalhar e se elas estão a fazê-lo da forma correcta para usarem o seu tempo. Debaixo deste foco é mais difícil esconder os projectos. Não será preciso encontrar uma desculpa para falar à equipa de projecto, mas as timesheets dão sempre uma boa. Reveja com eles o tempo gasto no projecto e peça sugestões acerca de áreas que podem ser melhoradas.

As previsões são mais acertadas

É muito difícil justificar que esteja quase a terminar numa actividade em que mesmo agora se mudou a previsão para permitir atribuir-lhe mais 20 horas. É fácil ao gestor de projecto ver quanto trabalho exactamente ainda tem de ser feito. Esta informação é de enorme valor para o plano do projecto e para a previsão do que vai acontecer durante o resto do projecto.

As estimativas têm mais significado

Para além de permitirem olhar para a frente com propósitos de previsão, as timesheet também permitem olhar para trás. Quanto tempo levámos a fazer os testes da outra vez? Será possível ter informação até à hora mais aproximada. Esta é informação realmente útil para quem tem de planear. As estimativas do trabalho futuro podem ser informadas e melhoradas com exemplos reais de como estas actividades forma realizadas no passado.

O registo de tempo pode ser um assunto desagradável para falar com a equipa, mas as ferramentas tornam fácil integrar este nos métodos de gestão de projecto. Quando possuir um registo robusto do tempo a funcionar e perceber a informação que consegue obter, vai querer para sempre com timesheets.

Quanto tempo para implementar a ISO 27001

Esta é a segunda pergunta mais comum no que respeita à implementação da ISO 27001. A primeira é, evidentemente, «quanto é que vai custar?». Bem, mas a resposta não é muito encorajante – porque a maioria das pessoas acha que se faz num par de meses. Só que isto não é realista – a duração mais aproximada se tudo correr bem é: cerca de 1 ano.

Claro que se pode continuar a produzir 50 documentos com fluxos, regras e normas em alguns dias e reclamar que temos regras em conformidade com a norma ISO 27001, mas isto não é aquilo que importa. O que queremos falar é sobre a implementação que faz sentido, que produz resultados – um menor número de incidentes, crescimento da eficiência, poupança de custos, etc.

Tempo para as fases de PLANEAR e FAZER

O esforço principal da implementação será gasto nas fases de Planear e fazer, ou seja, nas primeiras fases mandatórias nas quais são realizadas a avaliação de risco e análise de impacto no negócio e nas quais todos os controlos (incluindo os planos da continuidade do negócio) são implementados. A duração para estas duas fases depende, em primeiro lugar, da dimensão da organização.

• Organizações mais pequenas (até 50 colaboradores) normalmente implementam o standard em 8 meses.
• Organizações médias (até 500 colaboradores) implementam o standard de 8 a 12 meses.
• Organizações grandes (mais de 500 colaboradores) a implementação leva de 12 a 15 meses.

As companhias que arrastam estes projectos demasiado tempo, não conseguem terminar – em tais organizações nunca há suficiente reconhecimento da importância do standard, e assim os recursos financeiros e humanos dedicados ao projecto nunca são suficientes.

Quando falamos de tempo de implementação é importante referir que o trabalho de implementação da ISO 77001 e da ISO 25999 não termina com as fases Planear e Fazer – estes sistemas de gestão necessitam ser mantidos e melhorados (fases Verificar e Agir), o que significa que o trabalho na segurança da informação e na continuidade de negócio não é uma vez mas sim contínuo. Contudo, o esforço para manter e melhorar o sistema de gestão é bem menor que o necessário nas duas primeiras fases.

As coisas que aceleram a implementação

A duração que referimos acima depende de muitos factores, mas geralmente os seguintes factores irão acelerar a implementação:

Realizar a implementação como um projecto – se souber com exactidão quais são os objectivos, quem é o responsável e por quê, se os recursos estiverem dispo níveis e quais são os resultados, não só irá acelerar o processo, mas também aumentará as usas oportunidades de sucesso.

Se já tiver a ISO 9001 ou outro sistema de gestão – os standards não são diferentes de outros sistemas de gestão, o que permite utilizar alguns dos procedimentos e processo existentes e poupar entre 20 a 30% de tempo.

Se já possuir a funcionar muitos dos procedimentos e políticas de segurança / continuidade de negócio – a oportunidade de que a documentação existente seja aceitável para a ISO 27001/25999 irá reduzir o tempo de implementação; também por que já possui na organização uma compreensão acerca da segurança da informação e continuidade de negócio.

Possuir os modelos de documentação adequados – não quero dizer quaisquer modelos de documentação, mas modelos na própria língua, apropriados para a dimensão da companhia e feitos para o propósito das ISO 27001 e 25999. Os modelos livres da internet obrigam à tradução e adaptação, com frequentes revisões.

Possuir o conhecimento – este pode obter-se através da leitura, formação pessoal, cursos online, ou pela contratação de um consultor; sem o conhecimento o seu projecto irá levar mais tempo, e provavelmente nunca será concluído.

A última mas certamente a primeira – o apoio e compromisso da gestão – se este não for obtido e se não for comprometido efectivamente em recursos e em dinheiro, o projecto irá demorar mais ou será concluído mesmo antes de começar.

Em conclusão – a implementação de standards com o estes toma muito tempo o que força a que se faça com este propósito em mente. Se a implementação for realizada de forma superficial ou sem objectivos claros, não irá somente perder uma quantidade de tempo mas também perder uma oportunidade para ajudar a companhia a melhorar e a crescer.

LQ

O Controlo da Mudança

Continuamos hoje a falar do processo de controlo da mudança e a esclarecer como se pode implementar o processo com simplicidade.

O controlo de mudanças é uma parte importante do processo de gestão de projecto. No caso da Engenharia e Construção quase que podia afirmar que ninguém implementa um processo formal e piro ainda, as mudanças são muitas vezes utilizadas para resolver a má estimação inicial do contrato.

Mas, com o ritmo de mudança nos nossos dias é mais do que certo que os projectos enfrentam exigências de mudança durante a sua vida. Muito embora a mudança possa ajudar a assegurar que os projectos estão alinhados com as necessidades de negócio, é importante ter em conta que cada mudança deve ser cuidadosamente considerada e aprovada. Daí que o processo mesmo que deforma elementar deve ser criado na equipa de projecto.

O processo de controlo da mudança na gestão de projecto garante que todas as mudanças propostas durante o projecto são devidamente definidas, consideradas e aprovadas antes da implementação. Isto garante que nenhumas mudanças desnecessárias sejam realizadas e, assim, os serviços não são interrompidos e os recursos são eficientemente usados. Se isto não são benefícios importantes então pensem o que será se o processo não for implementado.

O processo de controlo da mudança contém 5 passos:

1. Propor uma mudança
2. Sumário do impacto
3. Decisão
4. Implementar a mudança
5. Fechar a mudança

Durante o processo são utilizados dois documentos:

1. Registo das mudanças: usado para registar todas as mudanças pedidas e decisões tomadas
2. Formulário de Registo de Mudanças: usado para documentar os detalhes da mudança, incluindo o seu business case.

Propor uma mudança

O processo, pensado desta maneira, oferece a capacidade de qualquer pessoa na equipa do projecto 8 mas incluindo o cliente) propor uma mudança ao projecto. A proposta deve incluir uma descrição da mudança e os benefícios esperados ou outra razão justificativa da mudança. A mudança é apresentada usando o Formulário de Pedido de Mudança e adicionada ao Registo de Mudanças do projecto.

Sumário do Impacto

O projecto é conduzido pelo Gestor do Projecto que irá considerar o impacto da mudança no projecto. Serão consideradas as seguintes questões:

• Custo quantificável de poupanças ou benefícios
• Razão para a mudança legal, regulatória ou outra
• Custo estimado da mudança
• Impacto na escala de tempo do projecto
• Recursos adicionais necessários
• Impacto em outros projectos ou actividades de negócio
• Novos riscos ou questões

Depois desta avaliação, o gestor de projecto recomenda se irá ser desencadeada a mudança.

Decisão

Este processo envolve a revisão do pedido de mudança por uma autoridade definida que irá considerar toda a informação obtida por quem fez o pedido e a avaliação de impacto do Gestor de Projecto. A decisão será usualmente:

• Aceitar
• Aceitar com comentários ou condições especiais
• Rejeitar
• Deferir (a mudança não é aprovada, mas poderá ser considerada mais tarde)

Implementar a Mudança

Se a mudança é aprovada esta será planeada, calendarizada e implementada na data acordada com os stakeholders.

Como parte do planeamento, deve ser elaborado um plano de regressão para o caso em que se deva recuar da mudança.

Depois da implementação é habitual levar a cabo uma revisão pós-implementação.

Fechar a Mudança

Quando o responsável pelo pedido de mudança dá o seu acordo a que a implementação foi correctamente realizada, a mudança é fechada e registada no Registo de Mudanças.

Gestão de Tempo num ambiente multi-projecto

Estou preocupado por que continua a haver pessoas que pensam que há aí no mercado o software de gestão de tempo perfeito que irá conseguir resolver os problemas dos seus planos. Na verdade este é um desafio que não pode ser ultrapassado só por tecnologia, pois há aspectos dos hábitos que jogam aqui, para além da natureza própria do desenvolvimento de software.

O manual do PRINCE2 declara que um membro da equipa só consegue realizar 3,5 dias de trabalho produtivo numa semana (no máximo)[i]. Outras actividades tais como reuniões, falar ao telefone, ir a uma festa da empresa, etc. ocupam todo o tempo remanescente.

A lei de Parkinson declara que as pessoas irão usar todo o tempo que têm para realizar uma actividade (por exemplo, para arrumar 1000 revistas são necessárias 2 horas, mas se dermos a uma pessoa 4 horas para isso, irá levar 4 horas). Mas esta noção é muitas vezes interpretada como poder sempre obter mais das pessoas se os espremermos, coloca-los sob pressão, dar-lhes prazos impossíveis de cumprir. Claro que isto pode permitir obter ganhos de curto prazo, mas o mais provável é resultar em desencorajamento das pessoas e diminuição de resultados.

Se pretendemos aumentar a produtividade, certamente existem outras formas possíveis de o alcançar.

Sabemos que um projecto está a trabalhar bem, quando os membros da equipa só colocam questões de dois em dois ou de três em três dias. O que significa que eles sabem o que fazer a seguir e não perdem o ritmo.

Muitas vezes, a deficiente gestão de tempo não decorre de mau agendamento, antes é uma questão que decorre da gestão de projecto. O gestor de projecto é responsável pela decisão das prioridades e não os membros da equipa ou os gestores de recursos. Aqui é que está o problema real, quando a gestão atribui prioridades sem compreender o peso e o efeito em outros projectos. Como a história da manta pequena e dos pés ou dos ombros alternadamente a descoberto. As pessoas preocupam-se demais com as datas de entrega quando deveriam enfrentar o desbaratar de tempo resultante da má optimização das práticas de planeamento.

Devemos ser realistas acerca da disponibilidade dos recursos. Temos de prever a realização de actividade em feriados e os tempos gastos em actividades fora do projecto ou não previstos. A semana de trabalho média é de 4 dias depois de se retirarem estes tempos. Destes quatro dias, pelo menos meio dia será gasto em outros deveres, como reuniões, actividades de gestão e de acompanhamento de outros projectos.

---

[i] Página 181. Managing Successful Projects with PRINCE2 (3rd Ed.)