Não culpem as pessoas! Culpem os processos!

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

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

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

 

O processo demorado

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

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

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

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

 

Processo de impasse

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

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

Keep it Simple

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

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

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

Em resumo

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

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

Um princípio fundamental na gestão de Incerteza

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

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

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

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

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

Reblogued from Herding Cats by Glen B. Alleman

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.

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

7 erros de planeamento a evitar

por Ten Six

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

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

1. Deixar de assinalar as actividades concluídas

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

2. Deixar de actualizar o progresso das actividades em curso

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

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

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

4. Dependências que estão em falta

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

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

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

6. Não planear para a disponibilidade dos recursos

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

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

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

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

O que é Planeamento?

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

O Planeamento de projecto consiste em:

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

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

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

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

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

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

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

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

 

Desenho do plano e Desenvolvimento do Cronograma

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

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

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

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

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

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