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

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

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


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

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

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

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

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

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

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

O que é receber relatórios de status precisos no PMO

Uma das importantes funções do PMO é garantir a consistência do reporting realizado sobre os projetos. Ora verificamos na prática que os relatórios nem sempre dizem o que deveriam e não salientam sempre de forma correta a realidade dos projetos.

Quando os gestores de projeto enviam os relatórios de status semanais ou mensais, começa para o Project Management Office o trabalho real. Mesmo que o software de gestão de projetos faça uma grande quantidade de tratamento de dados ainda há um elemento de interação humana para rever e verificar as informações antes que os painéis ou relatórios consolidados deixem o PMO.

Mas e se a informação que você está recebendo não parece precisa? Precisamos de confiança nos dados que sustentam os relatórios e que impulsionam a tomada de decisões. Embora o trabalho não seja adivinhar cada relatório que entra na In Box - afinal, devemos confiar nos gestores de projetos para corrigi-los – ajuda saber o que procurar se alguma dúvida houver.

Igualmente, é útil para todos que o PMO possa resolver quaisquer imprecisões nos dados antes que a direção, o cliente ou as partes interessadas vejam o relatório. Isso pode ser, como exemplo, de que o projeto está sendo relatado com um status de Verde já há algum tempo e, de repente, uma grande questão de orçamento "aparece do nada". Esse é o tipo de surpresa que os sponsors do projeto não gostam, e não fica bem para o PMO ou para o gestor de projeto.

Aqui estão algumas questões a serem observadas, para que possa detetar esses problemas antes que causem um problema maior.

Conversa de corredor

Se você está perto o suficiente da equipe – está a gerir um PMO, por exemplo, numa empresa com escritório único e não a tentar consolidar projetos de todo o mundo – provavelmente irá encontrar stakeholders e membros da equipe no prédio.

A equipe do PMO terá uma ideia de como os projetos estão indo pela atitude e pel a conversa. Escute o bem e o mal. Isso fornece um subtexto para os relatórios e pode ajudá-lo a identificar onde as coisas não correm como parecem.

Por exemplo, se o líder do projeto está constantemente a reclamar acerca de mudanças de âmbito e, no entanto, isso não está refletido nos dados que está a receber, deveria analisar isso.

Não se trata de controlar as pessoas ou tentar usar um café como desculpa para descobrir uma conspiração no relatório do projeto. É apenas usar todas as informações disponíveis, incluindo quaisquer conversas sociais relevantes, para avaliar se deve preocupar-se com o projeto.

Se não conseguir ligar-se pessoalmente com a equipe, há outras verificações que pode usar para rever a precisão dos relatórios de status do projeto.

Status de VAV

Cada um dos projetos reportará um resumo do status VAV (Vermelho, Âmbar, Verde ou Vermelho, Amarelo, Verde). Indica a avaliação do gestor do projeto sobre o status do projeto contra critérios pré-acordados, como orçamento e cronograma.

O relatório do projeto também incluirá uma declaração narrativa resumida – e desejavelmente os dois devem estar alinhados.

Por exemplo, um projeto com um status Vermelho, mas um texto que diz que "O projeto progride conforme o plano" mereceria uma investigação mais aprofundada. O que está errado? Avança na direção certa de acordo com o plano ou há algo que faz com que o projeto esteja marcado como vermelho?

Normalmente, há a tendência para informar o contrário: continuar a usar um status Verde quando o projeto é desafiado em termos de orçamento e datas. Esses desafios poderiam ser refletidos na narrativa e deveriam dar origem a um status que não é verde. Procure isso e sinalize com o gestor de projeto para uma investigação mais aprofundada.

Performance vs. Plano

Este é um teste rápido, mas pode dizer muito. Procura por duas coisas:

·         Orçamento planeado versus gasto real

·         Milestones planeadas versus atuais

Orçamento planeado versus real

Cada relatório deve incluir informações sobre o orçamento do projeto, pelo menos, mensalmente. Isso deve refletir os atuais versus os gastos planeados, por isso deve ser bastante fácil ter uma ideia se o projeto está batalhando ou não.

Os projetos em que o orçamento está a ser gasto mais rapidamente do que o previsto podem estar nessa situação devido a terem mais recursos ou terem que corrigir problemas que não foram antecipados, o que poderia ser uma baixa gestão de risco. Pode acompanhar o gestor do projeto se não estiver claro no relatório para apreciar, o que aconteceu para causar esse excesso. Estão agora confiantes de que está realmente resolvido e que estará de volta aos níveis de gastos previstos para o resto do projeto? 
  
Existe sempre o risco de os gastos serem executados nos níveis atuais e o dinheiro acabar.

Igualmente, estar abaixo do orçamento não é uma coisa boa. Provavelmente é causado pelo fato de o trabalho não estar a ser suficiente e assim também pode ver um atraso no progresso relatado.

Planeado vs Milestones Planeadas

Pode fazer uma verificação de sentido rápido na entrega do projeto e se está a progredir conforme o plano. Quais as milestones que devem ser alcançadas até à data? Foram cumpridas?

Caso contrário, poderia ser sinal de um problema, especialmente se o projeto estiver sendo reportado como Verde ou não há novos problemas marcados na narrativa.

Orçamentação e progresso são cobertos pela Gestão de Valor Ganho (EVM), então, se as equipes de projetos produzem ou fornecem narrativas, obterá esta informação sobre o desempenho num formato diferente. Os relatórios EV são tão bons quanto os dados fornecidos, e eles também devem estar sujeitos a escrutínio quando apropriado, mas são uma ferramenta sensata para usar e para suportar ou desafiar o status geral de projeto e as narrativas de texto no relatório de status.

O EVM não é um guia sobre como verificar os gestores do projeto na equipe do PMO. Em vez disso, ele deve ser usado como um ponto de discussão sobre como o relatório de status que eles fornecem é usado e como pode ser aperfeiçoado para melhor.

Em suma

A transparência e a honestidade são importantes para ajudar a direcionar um projeto e garantir que ainda tenha oportunidades de oferecer os benefícios. O "vermelho" não deve ser visto como algo a ser evitado. É a expressão do fato de que o projeto precisa de atenção de gestão para desbloquear um problema, fornecer uma decisão ou outra coisa. 

Se os gestores de projeto tiverem a confiança de que seus relatórios serão usados como forma de apoiar os projetos (e suas equipes), verá que receberá muitas menos inconsistências nos relatórios de status.

Categorias de Tipos de Atrasos em Projeto

Este post discute diferentes tipos de atrasos e respetivas compensações aplicáveis, mas estas são apenas orientações gerais. 

A remuneração real depende das condições do contrato e as cláusulas do contrato devem ser integralmente referidas antes de proceder a qualquer análise de atraso com base nos fatos discutidos abaixo:

Atrasos Escusáveis / Compensáveis

As ações ou inações do proprietário causam atrasos Escusáveis / Compensáveis. O contratante tem direito a prorrogação de prazo, bem como a compensação de danos para o custo extra associado com o atraso. Geralmente, os contratos de construção têm a obrigação implícita da parte do proprietário de não atrasar, interferir ou dificultar o desempenho do empreiteiro. Os principais fatores que levam a atrasos compensáveis são os seguintes:

Ordens de Alteração

As mudanças no âmbito do trabalho ou mudanças no método de trabalho, maneira ou sequência de desempenho pode exigir mudanças no cronograma ou milestones. A alteração pode ter um impacto direto no calendário e, por conseguinte, o contratante tem de ser compensado pelo atraso resultante da alteração e a pagar pelo aumento do custo causado pela alteração.

Condições Diferentes do Site

A condição latente mais arriscada em projetos de construção é a subsolo desconhecido. A subsuperfície ou as condições físicas latentes no local podem diferir materialmente daqueles mostrados no contrato ou o contratante pode encontrar condições físicas desconhecidas ou incomuns diferindo fortemente das normalmente encontradas.

Suspensões

De vez em quando durante o curso do trabalho, pode ser necessário ou desejável pelo dono da obra suspender todo ou parte do trabalho. Para ser compensável, a suspensão não deve ser causada de forma alguma pela falha ou falta do contratante.

Alguns exemplos de atrasos compensáveis ​​causados ​​pelo dono da obra são:

• Não entrega de desenhos necessários para manter o desempenho satisfatório do empreiteiro
• Falha em entregar o material fornecido pelo dono da obra ao contratado em tempo
• Não liberar o acesso ao empreiteiro para realizar o trabalho
• Interferir com o cronograma do contratado e ordenar para prosseguir sob condições
• Fornecimento de informações incorretas, que engana e interrompe o contratado no seu desempenho
• Falha na inspeção oportuna do trabalho concluído do contratado
• Exigir que o contratante utilize qualquer método particular quando o contrato não especifica qualquer método particular
• Falha no processamento oportuno de faturas, ordens de alteração ou emendas e submissões dos contratados.

Se o dono da obra ordena ao contratante para acelerar o trabalho para recuperar o atraso causado por parte do dono ou devido ao atraso Desculpável, o custo da aceleração torna-se compensável. Atrasos Escusáveis ​​são os atrasos causados ​​pelos Eventos Desculpáveis ​​que estão fora de controle das partes envolvidas e imprevisíveis.

Atrasos Escusáveis / Não Compensáveis

Os atrasos escusáveis não são nem a culpa do empreiteiro nem do proprietário. Ambas as partes compartilham o risco e as consequências quando ocorrem desculpas. O Contratante tem direito a prorrogação de prazo, incluindo o alívio de quaisquer danos liquidados contratualmente imputados pelo período de atraso, mas não a compensação de dano.

A intenção geral aqui é liberar o empreiteiro da responsabilidade pelo efeito de uma força superior que não pode ser antecipada ou controlada, normalmente referida como Força Maior. Isso geralmente inclui:

• Atos de Deus (Inundação, Terremoto, Ciclone etc.)
• Greves
• Condições meteorológicas extremas
• Fogo
• Atrasos anormais no transporte

Os seguintes critérios devem ser fixados para constituir um atraso desculpável, para evitar limitar os diferentes eventos:

• Além do controlo possível do empreiteiro
• Sem falha ou negligência do contratado
• Eventos imprevisíveis

Atrasos Não Escusáveis ​​/ Não Compensáveis

O contratante causa atrasos não justificáveis ​​/ não compensáveis ​​e assume o risco desses atrasos. As ações ou as inações do contratante ou subcontratado causam esses atrasos. Tais atrasos poderiam ter sido previstos e evitados pelo empreiteiro com o devido cuidado. O contratante não tem direito a qualquer extensão de tempo ou danos por este atraso. Por outro lado, o dono da obra pode ter direito a liquidação ou quaisquer outros danos. No entanto, há uma área cinzenta, que pode vir a ser atraso compensável um atraso não-desculpável.

Normalmente, é responsabilidade implícita do contratante e seus subcontratados prever e planear a interferência do site com outras partes que trabalham no local. No entanto, um atraso irrazoável, mesmo no caso de um evento que o empreiteiro foi aconselhado a antecipar, pode mudar um atraso não-desculpável para um atraso compensável. Exemplos são:

• Falha do dono da obra em fornecer a inspeção oportuna do trabalho concluído
• Falha do dono da obra em coordenar com toda a competência o trabalho de contratantes separados.

Analisamos agora o efeito de causalidade que pode ser provoicado num projeto por concorrência de efeitos.

Organização do projeto começa logo no início

A maioria dos projetos em que intervenho num esforço de consultoria no planeamento apesar de envolverem pessoas que muitas vezes trabalham juntas, enfrentam sempre problemas organizativos- Estas questões vão sendo resolvidas ao logo do projeto, mas sem uma intervenção consistente e coordenada. Frequentemente, o projeto termina sem uma organização de trabalho eficiente e isso irá destruir qualquer esforço de consolidação de lições aprendidas.

Uma perspetiva sã para esta questão, é considerar que tudo deve ser definido como se fosse a primeira vez. A realização de uma reunião para tratar desta questão, organizada como um workshop, é um primeiro passo para trocar experiências e comunicar métodos e processos utilizados pelas partes e definir os caminhos adequados.

Os participantes da equipa são profissionais com experiência e trazem com eles formas de trabalho e processos que partilhados com outros podem ser aceites melhorados e contribuírem para a definição de processo que facilitam a realização do projeto.

A documentação de um projeto é fundamental para garantir a comunicação e partilha numa realização deste tipo. Para além de todas a complexidade introduzida por processos internos de companhias, há um conjunto de práticas standard de estruturação da documentação que, sendo dirigidas ao ambiente temporário de projeto, são intuitivas para todos. Um exemplo de um sistema simples de documentação que pode ser utilizada em qualquer projeto:

• Documentação: pasta para todos os documentos de projeto 'oficiais' atuais, como documento de iniciação, documento de requisitos, etc.
• Planeamento: cópia mais recente do plano, mais documentos relacionados ao plano
• Versões anteriores: para cópias de arquivo, para que não se confundam com as versões atuais
• Desenhos e Engenharia: se o projeto envolve desenhos, mantenho todos separados.
• Financeiro e Contratual: uma pasta para tudo a ver com o orçamento e os contratos
• Relatórios: para relatórios semanais, relatórios de resumo e relatórios de informação executiva.
• Atas: para atas das reuniões, com uma subpasta para o executivo do Projeto
• Qualquer outra coisa específica para esse projeto que poderia ser dividida numa pasta separada.

Ficar organizado desde o início do projeto faz com que seja mais fácil estar em cima da informação e das decisões. Faz com que todos se sintam alinhados com a realização do projeto sem silos fechados de informação.

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.

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.

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.

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

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

Razões para falhar a mudança

As iniciativas de mudança nas organizações, como a implementação de processos novos ou alterados ou a utilização de novas aplicações para processos de negócio, falham muito mais vezes do que os responsáveis gostariam, mas isso é uma característica destas actividades que não deixa de acontecer só por que queremos. Há algumas razões principais que fazem com que estas iniciativas falhem e se as conhecermos talvez consigamos gerir e utilizar a nosso favor.

 

Uma visão pouco clara

A mudança atinge todos. Temos de fazer com que a visão para a nossa mudança seja mesmo muito fácil de entender para que toda a gente compreenda. A criação de uma visão clara significa trazer para cima da mesa aquilo que se pretende mesmo atingir. Se é implementar um processo para a gestão de projecto ou se é melhorar as taxas de sucesso dos projectos? Será que é a generalização de ferramentas de gestão de projecto como o Primavera P6 ou a recolha de melhores dados para gerir os custos dos projectos?

Uma das formas de garantir que a visão é clara é estabelecer como é que sabemos que alcançamos o propósito. Pense nas métricas que pode utilizar e que o ajudem a avaliar qual a proximidade para o seu objectivo. Conhecer como é que o sucesso se apresenta ajuda toda a equipa a trabalhar com efectividade na sua direcção.

 

Comunicação deficiente

Se perguntar qual é o maior factor de risco de uma iniciativa de mudança a resposta é: as comunicações. Algumas companhias até são muito boas a comunicar de cima para baixo e assim os projectos de mudança são lançadas com banda de música e foguetes. À superfície, pelo menos, todos sabem o conteúdo da última newsletter do projecto e como o trabalho deles irá contribuir para os objectivos gerais.

Mas a comunicação funciona nos dois sentidos. Para cima a comunicação é também importante. A comunicação das pessoas afectadas pela mudança para aqueles que a estão a implementar. Como estão as coisas a correr na linha da frente? Somente com métodos de comunicação efectiva para reunir o feedback é que quem dirige o projecto sabe como é que a mudança está a ser entendida – e, assim, se irá mesmo ser possível alcançá-la.

 

Falta de apoio na cultura da organização

A implementação de uma estrutura de processos numa companhia com uma cultura aberta e em rede irá funcionar com muita dificuldade. De igual forma, uma função de gestão de projecto altamente colaborativa sem apoio em metodologias estruturadas irá lutar para ter sucesso nas indústrias reguladas dos nossos dias. As grandes ideias de mudança são só início da viagem!

Teremos de conseguir que a forma como iremos implementar forneça um novo modelo de cultura para o negócio. Se não o conseguir, então mude, em primeiro lugar, a cultura.

 

Falta de direcção de topo

Infelizmente isto acontece todo o tempo e em todo o lugar. O responsável executivo da liderança da iniciativa muda de posição na companhia ou perde o foco e, no final, a mudança falha. Tem de haver sempre alguém no topo como proprietário da mudança e decidindo acerca da direcção das actividades que esta exige para ser alcançada. Esta pessoa é aquela que explicará aos colaboradores nas reuniões por que é que a mudança é tão importante. Será responsável, claro, pelo orçamento e prestará contas pelo resultado alcançado. Se perdermos o líder da mudança, considere parar o processo de mudança – pelo menos até conseguir encontrar outro executivo que funcione como campeão da mudança.

 

Declarar o sucesso demasiado cedo

Contratar um director não é um sucesso. Instalar o novo software não é um sucesso. Muitas iniciativas de mudança enfraquecem e morrem porque se instala um estado de «deixar andar». Há muito mais para fazer o sucesso de uma mudança do que o ligar de um interruptor. Nos dias iniciais a novidade pode ser suficiente para obter alguns benefícios, mas com o tempo, a não ser que haja apoio, as pessoas voltam às velhas formas de fazer as coisas.

Não desmobilize a equipa da mudança demasiado cedo. Assegure-se que a mudança transitou de facto para o negócio como a forma usual de fazer as coisas e resolva todas as questões que sejam colocadas. O melhor é descontinuar totalmente as formas antigas de os colaboradores fazerem as coisas. Os campeões da mudança de cada equipa podem ajudar porque podem descobrir lacunas e apoiar os colegas.

Mas o conselho mais importante é pensar naquilo que, no final, queremos alcançar. Se conhecemos o objectivo final, aquilo por que estamos a trabalhar, articulando e comunicando com outras pessoas torna-se muito mais fácil. Planeie para o estado final, garanta que sabe o que é que você quer e torne possível a todos realizarem a viagem até lá consigo.

Como planear um projecto Prince2

Um guia para gestores de projecto

"Um objectivo sem um plano é só um desejo." - Antoine de Saint-Exupery

O que é isto?

Planear é um processo muito natural. Todos os dias fazemos muitos pequenos planos (por exemplo, o que é que vamos ver na TV esta noite, onde é que vamos no fim-de-semana, onde é que vamos nas férias). O processo é tão natural que o mais provável é que nem sequer pensemos que se trata de planeamento, só mais uma forma da vida diária. O facto é directo, todos planeamos todos os dias e somos (como um todo) muito bons nisso.

 

De que se trata?

Tente sempre planear os projectos como naturalmente os planeia. Utilize o seguinte guia:

Comece por aquilo que pretende alcançar com o projecto (isto é, o seu objectivo) e decomponha-o em coisas que tem de fazer para o alcançar. Por exemplo, se quiser umas ‘boas férias’ no próximo ano (e pretender conseguir uma reserva barata) pode querer começar hoje o seu projecto da «próximas férias». Sabe que para ter umas boas férias tem de fazer uma reserva de férias, reserve também espaço num lar para o gato e assegure-se de que alguém toma conta dele. Numa data acordada terá de pagar a Reserva e fazer a mala e obter transporte para o aeroporto. São seis coisas (a que chamamos ‘produtos’) que temos de fazer para alcançar o nosso objectivo.

Comece pelo fim do projecto e venha de trás para afrente para ter uma ideia dos ‘produtos’ escolhidos, porque os produtos finais temos uma boa ideia do tempo que tem de estar definidos para os obter antes da obtenção do objectivo.

Faça a revisão dos tempos e assegure-se de que tem os ‘produtos’ pela ordem correcta. Muitas vezes é óbvio mas em outros casos não é assim tanto. Reserve algum tempo para garantir que alguma coisa que queremos fazer na próxima semana não esteja dependente de outra coisa que só pode ser iniciada no próximo mês.

A outra coisa que termos só de considerar nesta etapa é por alto quanto é que isto irá custar. Lembre-se que isto, neste momento, é só uma estimativa.

Possui agora um plano de alto nível (todas as coisas que (pensa) necessita fazer; nas datas que (pensa) necessitar delas). Agora decida o que tem de acontecer agora e/ou nas próximas semanas e chame-lhe a ‘primeira etapa’. Se apropriado divida o resto do projecto em etapas e registe-as no seu plano. Agora foque-se na sua primeira etapa e naquilo que tem de fazer. Para cada ‘produto’ na primeira etapa, deve responder a algumas perguntas específicas:

• O que tenho de fazer?
• Qual é o orçamento?
• Quem vai fazer o trabalho? E estará disponível para o fazer? (já falámos com eles e conhecem o projecto).
• Como é que vou saber quando está terminado na forma adequada?

Com a resposta a estas perguntas criamos um pequeno plano para a etapa e para que consigamos obter os ‘produtos’ completos.

A não ser que seja você a fazer o trabalho, não se preocupe com as tarefas passo a passo de como é que o trabalho será feito, antes acorde a sua realização com quem irá ser responsável por cada ‘produto’ e saiba como se irá manter em contacto. Isto é, Como e quando será informado do progresso e como irá ser comunicado se as coisas correrem de forma inadequada.

Finalmente, quando tiver concluído o seu plano, peça a toda a gente para olhar para ele e pense simular o que é que poderá correr mal. Isto pode parecer muito pessimista mas pode poupar tempo e esforço mais tarde. Para tudo aquilo que pode correr mal veja se pode fazer alguma coisa para reduzir as possibilidades de isso acontecer. Pense também o que poderá fazer se de facto correr mal. Mantenha todos estes riscos para o projecto num Registo do Projecto e reveja-os com regularidade.

 

Quem faz o quê?

Como gestor do projecto será o responsável pelos planos do projecto. Isto não significa, no entanto, que os deve escrever isolado, longe disso. Consulte as pessoas o mais possível, tente realizar workshops para incluir os outros no seu plano.

 

Quando é que acontece?

Planear é um esforço contínuo ao longo do projecto. Podem acontecer muitas coisas durante o projecto que o irão forçar a fazer mudanças controladas aos seus planos. Nenhum plano deverá sobreviver na sua forma original desde o início do projecto até ao seu fim.

 

Dicas e armadilhas

Se tem de usar uma ‘ferramenta’ como o MS Project, lembre-se que esta irá tentar e forçar o planeamento ‘não natural’, isto é, adicionar actividades individuais desde o início do projecto até ao fim, assim tente planear primeiro os ‘produtos’ e depois carregar os dados na ‘ferramenta’.

Planeia a próxima etapa antes do fim da etapa corrente. Quando chegar ao fim da etapa, apresente ao sponsor uma visão completa do que foi realizado até à data e o que é que pretende realizar na próxima etapa.

 

Documentos chave

 

O Documento de iniciação do projecto (PID)

O PID é o centro de toda a informação de definição relacionada com o seu projecto. Ou seja, os seus objectivos, o business case, as comunicações, o plano de qualidade, etc.

 

O plano do projecto

O plano do projecto compreende o seu plano de alto nível e o plano da etapa corrente. Pode ter muitas formas e isso exige que você garanta que usa alguma coisa apropriada para o projecto que está a gerir. Note que os planos de projecto são muitas vezes definidos dentro do Documento de iniciação do projecto (PID) em vez de num documento separado.

 

Descrições de produtos

A maneira mais fácil de chegar a acordo nos ‘produtos’ é utilizar descrições dos produtos – podem ser contidos numa folha de papel e deforma sucinta conter toda a informação que o gestor do projecto e a pessoa responsável pelo ‘produto’ necessitam para realizar com sucesso o produto.

 

Work Packages

Um work package destina-se a acordar uma relação de trabalho entre o gestor do projecto e o responsável pelo trabalho para a realização de uma parte ou de um ‘produto’ do projecto.

 

O registo do projecto

Detalha todos os riscos do projecto e toda a outra informação e é muitas vezes o documento mais útil a par com o PID e o plano.

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.

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.

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.