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

domingo, janeiro 29, 2017

Tipos de Risco no Planeamento

Os riscos de agendamento são ameaças e oportunidades que afetam de qualquer forma o sucesso do projeto. As ameaças comprometem a realização de metas em projetos, entretanto, as oportunidades aumentam a probabilidade de atingir esses mesmos objetivos.
Assim, os riscos podem ter bons ou maus impactos no nosso projeto, mas que tipo de risco podemos encontrar nos cronogramas de projetos?
Há principalmente dois, e eu digo "principalmente", porque alguns especialistas mencionam mais, embora estes pudessem ser considerados parte disto. Estes são INCERTEZA DE DURAÇÃO e EVENTOS DE RISCO.
Quando realizo workshops de identificação de riscos, apresento o exemplo a seguir para observar e compreender a diferença entre a incerteza e os eventos. Que depois se esclarece por si.

Um exemplo

Se eu perguntar, quanto tempo leva para ir de sua casa ao escritório, o que iria responder? Vamos dizer que a sua resposta é 45 minutos. Leva esse tempo quase todas as vezes, todos os dias. Mas isto não é sempre. Às vezes leva 40 minutos, talvez porque conduziu um pouco mais rápido, outros dias você faz 50 minutos apenas porque você fez uma pequena paragem para dizer olá a um amigo e, é claro, há dias que você leva apenas 45 minutos. Há, assim, incerteza na resposta de "45 minutos". Você deu a melhor estimativa. Alguns chamam-lhe de "média", embora não seja.
Agora vamos introduzir algo mais. Suponha que um dia há um acidente de trânsito sobre a sua rota e a estrada é fechada. Fica preso na estrada. Tem que conseguir outra maneira de chegar ao escritório, e esta estrada é mais longa. Naquele dia leva duas horas para chegar. Desta vez, aconteceu evento, e chegou tarde 1 hora e 15 minutos. Fora de qualquer previsão.
O mesmo acontece com as nossas atividades agendadas, oferecemos nossas melhores estimativas de duração, mas elas estão sujeitas a incerteza e a eventos que podem afetar a duração do cronograma de forma positiva ou negativa.

Modelar o cronograma com este tipo de análise de risco produz cronogramas mais realistas

O tratamento para cada um destes tipos de risco é diferente.

A incerteza é tratada com simulação de Monte Carlo, o que é realizado pelas aplicações que fazem gestão de risco. Neste processo executa-se um grande número de iterações com base na propagação e os limites das estimativas de duração, de modo que muitas combinações de durações são usadas.


Os eventos de risco podem ocorrer ou não durante o Projeto, a melhor maneira de modelar eventos é colocá-los num registo, que aborda as atividades com impacto, a probabilidade de existência e a magnitude do impacto nas atividades. Depois disso, pode executar cenários de hipóteses com os eventos de risco que têm maior exposição ao risco (probabilidade x impacto) adicionando fragmentos ao seu Cronograma e analisar os resultados. Se o evento realmente pode ter impacto no seu projeto, será necessário atenuá-lo de qualquer forma para reduzir o risco. Claro, que isso vai custar dinheiro.

terça-feira, fevereiro 23, 2016

Processo de Controlo e Hierarquia de Planos

Muitas vezes são referidos os níveis de planeamento em projetos de alguma dimensão, sendo mais usual quando se utiliza o Oracle Primavera P6. Vamos tentar descrever o que isso significa e para isso utilizo a designação de Level em vez da tradução para português.

Uma hierarquia de planos define o sistema de controlo de planos e alguns níveis interrelacionados de agendamentos. Esta hierarquia oferece uma estrutura de desenvolvimento para os agendamentos do projeto.

Primariamente, fala-se de 4 níveis de agendamento que são utilizados em projetos de média e grande dimensão para identificar o âmbito e sua divisão, bem como as milestones contratuais e de projeto.

Level I – Agendamento de Milestones e Sumário

Descreve a duração e prazo global do projeto, cobre o âmbito total do projeto e destaca marcos contratuais e de projeto. Este agendamneto é utilizado pela gestão para destacar eventos importantes e significativos, bem como para comunicar o âmbito global e o status de projeto. Este agendamento de nível 1 também pode ser utilizada para a tomada de decisões.

Level II – Agendamento total

Este agendamento é apresentado sumarizado por instalação, disciplina e áreas de Engenharia, com destaque para itens com grandes sobreposições, itens críticos de Procurement e sumarizado por resultado (work package) de Construção. O agendamento de Level II estabelece os requisitos ao nível de instalação, etapa e fase de trabalho. 

Descreve as relações entre instalações e fases e estabelece a criticidade das instalações.
O Level II é um plano com detalhe e representa uma etapa para a aprovação do Level III e acompanhamento regular do projeto.

Level III – Agendamento detalhado de Engenharia, Procurement e Construção

O Level III é o plano EPC integrado, onde a Engenharia é classificada por disciplina, agrupada por sistemas / área que descrevem os requisitos do sistema. Procurement identifica a procura por instalação / área ou sistema e assim identifica a entrega do equipamento principal. Construção / Preparação é agrupada por sistema / área que descrevem inter-relações e prazos. O agendamento de Level III estabelece a base para entregas e necessidades de pessoal nas atividades, materiais e requisitos de subcontratação e entregas de fases e as taxas de instalação. O Level III estabelece os requisitos de equipamentos de construção e integra a decomposição de instalação / área em dos pacotes de resultados do sistema. O agendamento Level III é mantido de forma regular e usado para análise What-if.

Em muitos casos este é o nível mais alto de desenvolvimento dos planos e os projetos são acompanhados a este nível através da manutenção de planos base.

Level IV – Identificação do plano detalhado de trabalho e lista de registos

O agendamento Level IV é detalhado até às atividades de trabalho, incluindo desenhos, especificações, trabalhos detalhados por pacote área / instalação, especialidade, equipa de trabalho e estabelece a sequência construtiva. Desta forma o Level IV oferece a base para o planeamento detalhado do trabalho de construção e planos pormenorizados, documentando o trabalho que é atualizado continuamente e revisto para refletir as necessidades do projeto e as circunstâncias em que evolui.

Este é o nível de detalhe requerido para projetos em infra-estruras de energia e do petróleo e gás em que é determinante manter traceabilidade dos trabalhos com os equipamentos no futuro sujeitos a manutenção

Processo de Plano Base do Agendamento


O agendamento deve ser sujeito a manutenção de plano base para mapear o plano corrente com o planeado e dessa forma se obterem avisos antecipados e se evitarem desvios. O processo é assistido ainda com o desenvolvimento de Curvas-S e histogramas para manter o plano corrente na linha.

quinta-feira, fevereiro 11, 2016

Progress Reporting

Se trabalha como gestor de projeto, é muito provável que você tenha dezenas de relatórios de progresso realizados durante a sua carreira - se não centenas! Mas foram mesmo eficazes? Teve um propósito claro ao escrever os relatórios, por exemplo, querer que os stakeholders tomassem determinada ação como resultado dos relatórios? Ou só os produziu porque era uma dessas atividades de rotina que tinha de ser feita?



Pode ter sido muito consciente e determinada ao produzir os relatórios, mas, infelizmente, nem todo mundo é igual, e como resultado, o relatório de status semanal torna-se um desses artefactos que faz parte do processo sem adicionar muito valor.

Erros Principais

Alguns dos erros clássicos que os gestores de projeto fazem é incluir demasiadas informações estáticas e não introduzir o suficiente sobre o que são os problemas do projeto real. Desta forma, o relatório não é um verdadeiro reflexo do que realmente acontece. Se acabou de escrever sobre o que aconteceu durante o último período de referência e o que você vai fazer durante o próximo período de referência, sem mencionar como isso se compara a planear e quais são os riscos reais e questões do projeto, então não há incentivo para que o cliente preste atenção a ele. Em muitos casos, o relatório é mesmo anexado num e-mail sem qualquer contexto ou descrição, o que significa que é improvável que alguma vez chegue a informação aos executivos que dependem de smartphones ou doutros dispositivos móveis.

O relatório de progresso perfeito

Então, o que é um relatório de status perfeito? Bem, em primeiro lugar, é um relatório simples, de preferência numa página de informação que adiciona valor real, fornecendo uma visão geral das milestones, riscos, questões e informação de custos, no mínimo.

Algumas orientações sobre o que se deve e não deve fazer:
  • Não inclua demasiada informação estática acerca do background do projeto, a não ser que seja parte do processo.
  • Inclua sempre o nome do sponsor e do gestor de projeto.
  • Mantenha a informação viva numa página só.
  • Inclua os 5 riscos e questões principais, incluindo o responsável e ação de mitigação.
  • Inclua informação sobre o orçamento e como se está a acompanhar.
  • Inclua uma visão geral das principais milestones, as suas datas planeadas e o estado de cada uma delas.
  • Faça uma lista das realizações chave do período anterior.
  • Faça referência a métricas importantes alcançadas, mas faça-o de forma simples e gráfica.
  • Seja claro quanto às ações que quer que sejam feitas; este relatório é só para informação ou requer-se uma decisão de alguém?
  • Não envie o relatório por email sem fornecer o contexto no corpo do email. Os destinatários podem nunca ler o relatório, então forneça um sumário no email.
  • Não envie más notícias num relatório de projeto sem antes falar com as pessoas. Não queremos que o cliente leia acerca de 

segunda-feira, abril 20, 2015

Medir o Progresso: os 6 métodos que deve conhecer

Por Reshma Sadhu, traduzido para português

Medir o progresso de um projeto com precisão é sempre um desafio. Há muitos fatores para ter em atenção numa atualização de progresso - tipo de medição, a precisão dos dados, a frequência da recolha e o sistema de registo são todos fatores importantes para medições precisas de progresso.
E os pacotes de software como Primavera P6 nem sempre nos ajudam. Claro que há 3 escolhas para a Percentagem de Conclusão, mas como decidimos qual delas funciona melhor e em que condições?
O progresso impreciso vai frustrar a capacidade de detetar os sinais precoces de problemas à frente, assim para evitar isso aqui estão os 6 métodos comuns para medir o progresso do projeto que irão ajudá-lo a ter um melhor desempenho na medida da performance do trabalho e sua conclusão. Os métodos abaixo são resumidos a partir de “Project Control: Integrating Cost and Schedule in Construction,” by Wayne Del Pico.


 

Unidades Concluídas

As unidades concluídas de trabalho (Labor) prestam-se bem para o acompanhamento de atividades que são feitas repetidamente, onde cada iteração pode facilmente ser medida. Normalmente, uma atividade que é feita repetidamente tende a ter aproximadamente a mesma quantidade de tempo, recursos e esforço, de modo que rastrear as unidades concluídas é bem fácil. Um exemplo simples pode ser a instalação de luminárias padrão. Cada equipamento leva aproximadamente o mesmo período de tempo; se tivéssemos 100 luminárias para instalar então poderíamos simplesmente contar as unidades instaladas. Neste caso, não há envolvido nenhum julgamento subjetivo baseado na experiência.


 

Milestones incrementais

Também conhecido como o método dos "passos", o método de milestones incrementais é predominantemente utilizado para contas de custos que envolvem sub-atividades que precisam ser concluídas de forma ordenada. Um exemplo desta técnica é a formação e colocação de uma parede de fundação de betão.

Então, como calcular esses dados? O cálculo é construído em cada etapa item único e valor orçado de tempo (horas de trabalho), que é necessário para completar a atividade, a equipe de construção. À medida que cada passo esteja concluído, é documentada como uma mini-marco que representa uma percentagem do processo de instalação total. O percentual determinado para cada sub-atividade pode variar de acordo com o projeto e este progresso é geralmente acordado para ser usado como uma medida de antemão. Uma boa maneira de implementar este método em Primavera P6 está usando Activity Steps.


 

Início / Fim

Este método só está focado em capturar o ponto de partida e o ponto de chegada da atividade e nada entre estes pontos. Este método é melhor para as atividades que são de curta duração. Implementará esse método se as estimativas de trabalho da atividade não estão disponíveis ou se os dados de progresso completo em percentagem são muito difíceis de recolher.

Usando a técnica de Início / Fim ganha uma percentagem do progresso quando a atividade começa e a outra metade é ganha quando a atividade estiver concluída. Essas percentagens são determinadas pelo proprietário e contratante do projeto.
Muitas vezes, as empresas comprometem-se a usar a Regra padrão 50/50 ou outras regras:

Regra 50/50 - uma vez iniciada a atividade é marcada como 50% concluída, e a outra metade é ganha à conclusão final do trabalho.

Regra 20/80 - usada para controlar atividades de maior valor que toma mais tempo para chegar a conclusão.

Regra 0/100 - a regra ilustra que só quando 100 por cento da atividade estiver concluída, o valor é ganho.


 

Rácio de Custo

O método Rácio Custo é normalmente implementado num projeto que tem atividades que tendem a ocorrer ao longo de uma longa fase ou durante todo o projeto. Muitas vezes usada para despesas gerais, esta técnica é medida com base na alocação orçamentada em dólares contra as horas de trabalho de produção. Este método dá ao empreiteiro a capacidade de ganhar valor correspondente à percentagem global de conclusão do projeto.

No Primavera P6 é obtido pela utilização de atividades do tipo Level of Effort.


 

Experiência / Opinião

Ao contrário dos métodos acima que dependem de dados definitivos, este método baseia-se na experiência e subjetividade do gestor de projeto. Não é geralmente recomendado e tende a ser visto como o último recurso, porque as experiências e opiniões de cada indivíduo variam entre si e podem causar conflito entre proprietários, empreiteiros e arquiteto.
 

Unidades Ponderadas ou equivalentes

Este método foi destacado como a melhor técnica e é o que exige mais esforço, mas também se estende a uma gama mais ampla de dados. As atividades que estão sendo calculadas tendem a ocorrer ao longo de um tempo de duração mais longa e incluem várias sub-atividades, que podem ter diferentes unidades de medidas.
A fim de concluir este projeto que exige várias unidades, horas de trabalho, recursos e sub-atividades e, para calcular as sub-atividades, é ponderada um nível estimado de esforços em horas de trabalho ou em valor monetário que é específico de cada sub-atividade. Uma vez que o valor ponderado é determinado, este é convertido para refletir o valor em unidades de medida específicas para a atividade. Após o que se atribui unidades equivalentes de percentagem de conclusão do projeto global.

Estes 6 métodos para medir o progresso do projeto são comummente usados em gestão de projetos de construção e são filtro para um processo de determinar a percentagem de conclusão para o projeto como um todo com Earned Value Management.

Qual destes métodos usa mais nos projetos?

terça-feira, dezembro 23, 2014

A Implementação BIM e o Controlo do Projeto

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

O que é o BIM?

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

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

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

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

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

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

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

Ineficiências e falta de produtividade

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

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

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

Em conclusão

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

sexta-feira, novembro 21, 2014

Realizar o Plano

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

A meta é chegar rápida e facilmente a:

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

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

Planeamento

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

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

  

Configure o plano

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

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

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

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

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

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

Veja e trabalhe sobre os resultados

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

Em seguida

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

 

A utilização do Excel

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

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

quarta-feira, junho 04, 2014

Chegar a acordo com a Data de Conclusão

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

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

A data indicada

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

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

A data agendada do projeto

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

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

A data negociada

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

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

segunda-feira, março 31, 2014

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

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

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

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

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

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

  • Planeamento
  • Controle
  • Gestão

 

Planeamento de um projeto

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

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

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

 

Controlar um projeto

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

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

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

 

Gerir um projeto

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

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

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

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

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

Reporting de Risco em Projetos

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

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

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

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

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

Não incluir:

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

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

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

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

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

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

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

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

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

terça-feira, janeiro 21, 2014

O que espera o cliente do projeto e da equipa?

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

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

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

Comunicação Frequente

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

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

Disponibilidade a todo o tempo

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

Bom reporting de status

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

Uma equipa que sabe o que está a fazer

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

Atualize o agendamento do projeto

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

segunda-feira, outubro 07, 2013

Um princípio fundamental na gestão de Incerteza

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

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

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

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

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

Reblogued from Herding Cats by Glen B. Alleman

segunda-feira, julho 22, 2013

Gerir trabalhadores remotos

Por Ten Six traduzido e adaptado

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

Há alguns cuidados que os gestores devem ter como:

Garantir que todos têm acesso às mesmas ferramentas

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

Inclua os trabalhadores remotos nos eventos sociais

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

Estabeleça objectivos claros

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

Forme toda a equipa

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

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

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

Mantenha-se organizado

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

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

segunda-feira, maio 06, 2013

7 erros de planeamento a evitar

por Ten Six

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

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

1. Deixar de assinalar as actividades concluídas

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

2. Deixar de actualizar o progresso das actividades em curso

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

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

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

4. Dependências que estão em falta

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

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

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

6. Não planear para a disponibilidade dos recursos

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

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

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

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

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

O livro na Amazon

Planear projectos de grande dimensão com  Oracle Primavera P6

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

Pode comprar aqui Gestão com Oracle Primavera P6.

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

Não tem Kindle?

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

Free Reading Apps

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

Estou a finalizar a versão inglesa.

Book Description

Publication Date: January 31, 2013

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


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

segunda-feira, outubro 15, 2012

Começar os projectos com o pé direito

A preparação é uma parte chave na gestão de projecto. Se o projecto não começar de forma correcta irá ter problemas como refazer o trabalho, O âmbito indeterminado, atrasos no plano, má estimação, etc. Embora alguns pensem que o importante é saltar para o trabalho com as duas mãos, o gestor de projecto precisa de ajudar a oferecer um ponto sólido de partida para o projecto. Este ponto de partida é que muitas vezes determina se o projecto vai ou não ter sucesso, representa o ponto de partida do projecto e da equipa, e merece todo o tempo e esforço que se faça para garantir que se apoia em sólidos alicerces. Não se pode saltar às cegas para qualquer coisa que não está perfeitamente compreendida pela equipa.IMG_2259
 

O âmbito

A gestão do âmbito é uma parte importante da gestão de projecto. Muitos projectos iniciam-se com a visão de uma pequena cascata e os stakeholders acabam a dizer que querem as Cataratas Vitória. A gestão de âmbito irá ser uma parte da gestão de projecto ao longo de toda a sua vida, mas há alguns passos que o gestor de projecto deve tomar no início para minimizar as questões com o deslizar do âmbito.

O primeiro passo é definir o âmbito para o projecto; esta definição não tem de ser muito detalhada, mas tem de ser compreendida por todos os envolvidos. O segundo passo (e muito mais difícil) é obter aprovação formal para o âmbito. Esta assinatura pode ser de um documento legal ou pode ser um acordo entre o sponsor e o gestor do projecto. Em qualquer dos casos, é necessário sublinhar para todos que se o âmbito for alterado terão de haver alterações do projecto. A definição de âmbito deve ser claramente compreendida antes de começar o trabalho ou existirão problemas no futuro.
 

Baseline

Depois de o âmbito ter sido definido e acordado pode então ser desenvolvido um rascunho dum plano base. Este não terá de incluir todas as pequenas actividades que serão realizadas pela equipa do projecto, mas deverá incluir as milestones chave e o desenho de como o trabalho do projecto será executado. Esta baseline inicial será o primeiro passo para o plano completo do projecto que será desenvolvido e actualizado durante o projecto. Tal como o âmbito, esta baseline preliminar deve ser compreendida e formalmente acordada pelos stakeholders e o sponsor do projecto antes que o trabalho do projecto se inicie. Conforme esta baseline inicial vai sendo desenvolvida, o gestor do projecto deve apresentar e definir como serão os status do projecto apresentados ao sponsor do projecto durante a sua execução.

 

Organização da equipa

Um último ponto que deve ser compreendido cobre a equipa que irá trabalhar no projecto e que é a necessidade de estabelecer a forma de funcionamento da equipa. Dê a conhecer a todos os recursos quem é que está na equipa e quais são as suas funções nesta. É muito importante comunicar quem será responsável por quê e como prestará contas desta responsabilidade ao gestor de projecto.

Ser aberta e honesto acerca do trabalho do projecto e como o projecto será gerido é o melhor caminho para pôr, de imediato, a equipa do projecto a colaborar. Fazer com que a equipa de projecto esteja motivada de início para o trabalho do projecto passa assim por todos conhecerem as funções e as responsabilidades mútuas.

Kenneth Darter e LQ

segunda-feira, junho 18, 2012

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.

quinta-feira, junho 14, 2012

Proteger e servir

Vem esta conversa a propósito de estar 3 dias a falar sobre a auditoria das TI e a dificuldade de manter o investimento quando a auditoria é utilizada para garanntir que é suficiente a proteção em posição.

Este lema é certamente bom para as TI, como para outras actividades mais ‘bélicas’. Ouvimos dizer muito este lema, por que parece ser o lema da polícia dos EUA e soa como uma coisa das «berças» que se usa nos filmes.

Quando olhamos para as TI parece-nos que estas só existem para criar novas respostas de TI para satisfazer as necessidades do negócio. De facto, isto não é verdade!

Servir sabemos que é o seu propósito mas também protegem.

O Departamento Financeiro não existe somente para encontrar dinheiro para quaisquer que sejam as necessidades do negócio. O departamento financeiro também existe para se preocupar com a saúde e a segurança da organização. Por vezes o departamento financeiro irá resistir a novas iniciativas simplesmente porque a organização não tem possibilidade para as custear. Esta então faz tudo para que a sua posição seja escalada para o Executivo ou para o Conselho de Administração para este decidir se prossegue ou não contra a opinião do responsável financeiro.

Da mesma forma, o departamento de TI existe para proteger os interesses das TI, dos responsáveis da organização, ao mesmo tempo que servem os seus clientes e os utilizadores. Os dois interesses algumas vezes não se alinham. A fixação corrente no Cliente – o culto do Cliente – pode ser errada e perigosa. O departamento de TI deve proteger os activos de TI da organização. Esta actividade inclui:

· A própria informação, a sua confidencialidade, integridade e disponibilidade;

· O investimento nos sistemas existentes para gerir, suportar e usar a informação;

· A capacidade para implementar sistemas novos e alterados: arquitectura, análise, desenho, desenvolvimento e implementação.

Algumas vezes, não é do melhor interesse da organização abandonar estes investimentos ou aumentar os riscos para a confidencialidade, integridade e disponibilidade da informação, de forma a responder a novas necessidades para novas TI para os clientes ou, por outro lado, por que o departamento financeiro considera que não há dinheiro para os custear.

Em qualquer dos casos, as TI devem resistir (aconselhar em desfavor) à mudança e escalar para o Executivo ou para o Conselho de Administração para este decidir se prossegue ou não.

As TI não podem ser encaradas só como um centro de custo, pelo contrário, se as suas principais actividades têm a ver a defesa da informação avultam sempre as destinadas ao prosseguimento do investimento e em apoio e resposta às necessidades dos seus clientes – o negócio. Sem este esforço de investimento, a resposta do negócio ao ambiente seria inadequada e impediria a obtenção dos resultados positivos que permitem a afirmação e desenvolvimento da organização.

Luis Quintino

segunda-feira, junho 04, 2012

Melhorar o controlo da Performance dos projectos

Porque é que falhamos nas tentativas para melhorar o controlo da performance dos projectos?

Há uma série de razões esta falha. Destacam-se as seguintes que podem ocorrer em combinação:

  1. Tentar resolver os problemas com as iniciativas grandes e / ou estratégicas sem verificarem que deixam de fora projectos que de repente se tornam de prioridade 1. Ignoram ainda pequenos projectos que consomem demasiados recursos.
  2. Focar-se em melhorar o trabalho dos gestores de projecto, com frequência de acções de formação ou workshops, mas estes não obtém, na realidade, competências referentes com o mundo real.
  3. Partir do princípio que os seus executivos sabem a sua função nos projectos e que oferecem uma visão clara do valor de negócio dos projectos e orientam os mesmos estrategicamente.
  4. Assumir que os executivos sabem priorizar os projectos e alocar os recursos em conformidade. Mas devemos perguntar-nos porque é que nas fileiras de quem faz o trabalho há tantas dúvidas acerca das prioridades dos projectos.
  5. Queixar-se das surpresas que enfrentam já tarde no decurso dos projectos quando muitas vezes já não há forma de as solucionar.

Há, no entanto, alguns elementos chave que melhoram o sucesso dos projectos na organização.

Uma metodologia consistente

Deve ser implementada uma metodologia de gestão de projecto que seja usada com efectividade por toda a organização. A metodologia não deve criar documentos desnecessários e antes deve ser simples e escalável com um mínimo de relatórios e de reuniões.

Tem de cobri toda a duração do processo de gestão de projecto, desde o início até ao arquivo da informação do projecto.

A metodologia deve fazer os planos de projecto muito mais quantitativos e muito menos subjectivos, o que se baseia no estabelecimento de definições de sucesso medido (métricas) para todas as actividades do projecto.

 

Temos de gerir todos os projectos

A organização deve gerir todos os projectos e não só os grandes. E têm de ser geridos com a mesma metodologia e usando as métricas acordadas. Se não for assim os recursos podem estar a ser gastos em actividades desnecessárias ou com prioridades descoordenadas.

 

Controlo firme durante a Iniciação

O que começa bem tem mais oportunidades de sucesso. Apesar de ser uma verdade quase absoluta, o que encontramos nas fases de iniciação dos projectos são muitas vezes demonstrações de caos organizacional. A fase de iniciação exige a definição clara das responsabilidades, uma identificação do valor do projecto, a definição de um rumo preciso e a preparação cuidada dos resultados a obter com o projecto.

Definição de prioridades para os recursos

A prioridade atribuída ao projecto irá influenciar a alocação e, por vezes, a qualidade dos recursos. O que devemos reter é que a alocação real dos recursos determinará a entrega dos resultados do projecto e o seu sucesso.

Todo o cuidado que possa ser atribuído aqui para alocação realista e equilibrada dos recursos do projecto terá influência na performance deste e dos outros projectos da companhia. Esta é uma actividade que envolve muita ‘política’ na organização e a negociação das prioridades.

Relatórios de progresso

Os relatórios de progresso são uma ferramenta para evitar e solucionar questões, evitando descobrir os problemas demasiado tarde. A definição e utilização de métricas com significado nestes relatórios é essencial para os tornar importantes para todos os intervenientes na sua apresentação (das equipas ao gestor do projecto). A métrica de estimado para conclusão em comparação com o planeado vai de terminar um valor que envolve todos e que permite entender onde estão as questões e riscos do projecto.

 

Em conclusão

Estas indicações permitirão melhorar a gestão de projecto e conduzir à criação de um ambiente controlado e medido para as equipas, os gestores de projecto e os executivos que permitirá o controlo de todo o processo.

A utilização das adequadas ferramentas empresariais de gestão de portfólio e de projecto apoiará decisivamente os avanços na maturidade da gestão e na realização com sucesso dos projectos.

quarta-feira, maio 30, 2012

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.