Planear Projectos: os grupos de processos

Todos os gestores de projecto necessitam de ter um plano transparente para o seu projecto. Esbarram logo com questões de: como devem criar o plano? Deve ser criado sempre da mesma maneira? Em que estágio deve registar as dependências, as baselines e a execução real?

Estas são questões comuns e que têm respostas.

Não importa qual a indústria em que trabalha ou em que projecto está envolvido, porque pode usar estes cinco tópicos para se orientar no planeamento do seu projecto.

Estabeleça uma Direcção

Antes de iniciar, defina a orientação para o seu projecto. Faça isso com clareza através da identificação da visão do projecto, dos seus objectivos e resultados. Declare a linha de tempo global para a conclusão e clarifique a quantidade de recursos disponíveis (incluindo financeiros). Determine o que está «dentro» e «fora» do âmbito do projecto. Identifique os benefícios e custos na execução do projecto e quais as milestones e constrangimentos que o afectam. 

Só quando tudo isto está acordado com o Sponsor do Projecto, será claro o que será necessário alcançar. Em poucas palavras, clarificámos a Iniciação de um projecto.

Selecção das Actividades

Está agora em condições de iniciar o planeamento. Comece por identificar os grupos de actividades que é necessário realizar para concluir os resultados do projecto. De seguida, para cada grupo de actividades, decomponha-os em subactividades para criar aquilo que é denominado como "Work Breakdown Structure" (WBS). A sua WBS é essencialmente uma lista hierárquica e ordenada de actividades. Atribua, agora, data de início e de fim a cada actividade, bem como durações das actividades. Adicione sempre um tempo extra (p. ex. 10%) às suas durações para ter alguma contingência. Seguidamente, adicione Milestones ao seu plano – estas são actividades que representam as maiores realizações ao longo do processo.

Interligação

O próximo passo é estabelecer ligações (ou dependências) entre actividades do projecto. Embora existam vários tipos de ligações, a maioria dos gestores de projecto usam ligações de fim para princípio, de forma que uma tarefa inicia-se quando outra termina. Para tornar o projecto realizável, adicione só ligações se existir uma dependência crítica entre elas. Lembre-se que quando uma actividade desliza no tempo, todas as actividades ligadas a esta irão também deslizar. Utilize as ligações com cuidado.

Atribuição de recursos

Chegamos agora à parte engraçada – atribuir recursos. Um «recurso» pode ser uma pessoa, um equipamento, uma localização ou materiais. Em relação a cada actividade do seu plano atribua um ou mais recursos necessários para a concluir. Conforme vai atribuindo recursos verifique a sua utilização. Por outras palavras, assegure-se que não sobre atribui um recurso específico a múltiplas actividades, de tal forma que se torne impossível a este recurso completar tudo o que lhe foi atribuído. Necessita de uma visualização da utilização dos recursos que lhe permita saber o seu calendário em projecto.

Baseline, Dados Reais e Reporting

Com um plano de projecto completado está finalmente em condições de guardar a sua «baseline», para que mais tarde possa comparar o seu progresso em relação ao plano. Comece a registar o seu progresso real em relação ao plano. Todos os dias registe a quantidade de tempo que despendeu em cada actividade. Registe, também, as novas datas planeadas de início e fim e monitorize a data global de conclusão do projecto. Reporte o progresso regularmente, para que possa controlar a entrega dos resultados do projecto e alcance os objectivos que estabeleceu.

Deixe de procurar uma «receita»

Os passos para «fazer ITIL», ou seja, resolver problemas complexos nas TI…

Se olhar para a quantidade de livros de ajuda, métodos, esquemas ou outros métodos, o seu primeiro passo será admitir a realidade e confirmar que está perante um problema. Pois, este problema é que continua a pensar que problemas complexos têm soluções simples, mas se isso fosse verdade já não existiam problemas para solucionar?

A inclusão de componentes da infra-estrutura de TI como um conjunto de serviços de TI que permitem directamente alcançar objectivos de negócio não é simples. É muito complexa e conforme o mundo e a tecnologia continuam a ficar mais complexos ainda se torna mais difícil obter mesmo um sucesso marginal na sua realização.
O primeiro passo verdadeiro é uma compreensão que os profissionais de TI, a todos os níveis, devem desenvolver um conhecimento aprofundado sobre a natureza dos problemas enfrentados na implementação de serviços de TI. Não há solução rápida, simples ou «ITIL in a Box».

Siga ou lidere, mas saia do caminho!

Esta é uma questão difícil porque aquelas poucas organizações que podem reclamar algum sucesso também podem afirmar que tinham uma boa liderança das TI bem como da empresa no seu conjunto.
A razão da grande importância da liderança é que qualquer implementação de processos da gestão do serviço, ou de outra framework de processos, metodologia ou adopção de standards exige uma mudança fundamental na forma como as pessoas executam as suas funções. Os bons líderes construirão uma visão para um «mundo melhor» e ajudarão os participantes a verem por eles essa visão.
Com efeito, qualquer esforço para a mudança da forma como as pessoas trabalham exige um esforço significativo na gestão dessa mudança. Os executivos das TI que «’ouvem» sobre a ITIL e querem por decreto «ir para a ITIL» não irão ter sucesso. “Fazer ITIL” requer que a equipa de gestão executiva das TI «viva e respire ITIL». Exige-se um compromisso da gestão que não pode ser só um envolvimento.

continua com Nada substitui saber do que se está a falar.

Melhorar o conhecimento sobre projecto

Pretende melhorar as suas competências em gestão de projecto? Quer melhorar as oportunidades de sucesso em projecto? Para isso precisa de aprender qualquer coisa nova todas as semanas sobre gerir projectos, porque se não aprende como pode melhorar?

1. Seja sério

Quer seja um principiante ou um aprendiz, tem de investir em aprendizagem formal para melhorar as suas competências. Pode, ainda, frequentar um curso ou tentar ferramentas online.

De qualquer forma, tente reservar duas horas por semana para ler livros, materiais, artigos acerca de projectos. Através da sua dedicação ao tópico, irá desencadear novas ideias para os seus projectos e para alcançar mais sucesso.

2. Alargue o seu horizonte

Não se reduza à teoria clássica da gestão de projecto. Ao contrário, alargue o seu horizonte através da leitura de outros materiais sobre a gestão de pessoas, dinheiro e equipamento, bem como, fornecedores, compras e comunicação.

3. Tire apontamentos

Se está a ler pela noite dentro, muito daquilo que lê é esquecido. Assim sempre que pensa «este é um bom ponto!» escreva-o. Crie o seu próprio Guia de Leitura e registe nele as dicas e ideias que foi lendo nos seus estudos.

Em seguida, pode sempre recorrer a este guia para refrescar as ideias. Melhor ainda, pode utilizá-lo para partilhar com a sua equipa o seu conhecimento adquirido. Quem sabe, se não publico um livro com essas ideias.

4. Seja específico

Depois de estar um par de meses a melhorar o seu conhecimento de gestão de projecto está em condições de ser específico. Seleccione as áreas em que está ainda fraco e recolha materiais sobre esses tópicos, Lembre-se que os Gestores de Projecto são generalistas. Tem de saber muito acerca de TODOS os tópicos na disciplina de gestão. Aprofundar os tópicos em que é fraco é assim uma opção decisiva.

5. Recompense os seus esforços

Como foi escrevendo ao longo do processo de aprendizagem, consegue rapidamente concluir o valor que esta informação tem para si. Em primeiro lugar, pela alteração para melhor das práticas diárias de gestão. Fique orgulhoso daquilo que aprendeu e ofereça-se um prémio. Faça alguma coisa especial para si ou com a equipa.

A atribuição de recompensas melhora a motivação e reforça a importância da aprendizagem. Motive-se semana a semana para continuar a aprender.

A ITIL só por si não resolve!

Nas Tecnologias da Informação em ambiente de empresa, em cada dia, há mais problemas para resolver do que os que podem ser solucionados. Para cada problema complexo, quando não se analisa a fundo, encontra-se sempre uma solução simples e atractiva que está errada. Para muitos, a solução simples está na ITIL.

Esta ilusão de simplicidade é idêntica à que o Rei tem acerca das suas roupas finíssimas. Para se ter sucesso com a ITIL temos de compreender porque é que o Rei não tem roupa…
Todos estamos de acordo que as práticas que encontramos na ITIL correspondem a objectivos com valor, mas então porque é tão difícil encontrar organizações que tiveram sucesso real na implementação de mais do que os processos básicos da ITIL?
Muitas organizações acabaram com dezenas de milhares de euros enterradas em ferramentas consultoria e formação – só para acabarem com ferramentas dispendiosas, geridas e suportadas por consultores bem oleados; com um lote de pessoas certificadas ITIL a pensar em por que é que o que fazem não tem nada a ver com aquilo que aprenderam na formação.
É claro, seria fabuloso que tivéssemos a colaboração total do negócio e que os clientes soubessem definir com clareza a qualidade e a quantidade dos serviços de TI que necessitam e que estes serviços possuíssem uma valor estabelecido e claro para a empresa. Bem e quem não quer “restaurar rapidamente serviços de TI que não funcionam” ou #descobrir e remover a causa primária dos problemas”. Já para não mencionar “perceber o conteúdo e o contexto da infra-estrutura”, “ avaliar com propriedade o impacto das mudanças” e “implementar as mudanças sem provocar dano” e, mais, toda aquela coisa de compreender e controlar os custos das TI.
Mas nós não fazemos, eles não conseguem e nós não podemos – pelo menos a fazer as coisas da forma como as estamos a fazer. Na verdade o Rei ITIL não está a usar nenhumas roupas. Vai nu!
Tem de haver uma forma qualquer de iniciar o caminho e começarmos a responder aos problemas dos serviços de TI, em conformidade com a ITIL, mas de acordo com uma metodologia consistente.
Continua com Deixe de Procurar uma Receita

A segurança é uma decisão de negócio

A quantidade de risco que um negócio pode assumir é determinada pela sua própria cultura, a sua sensibilidade de risco da sua reputação e a sua tolerância à perda.

O propósito de alinhar a segurança das TI com a do negócio vai muito mais longe do que garantir que todos têm a mesma pauta de música e estão afinados. A chave está na existência de uma boa política de aceitação do risco para que os objectivos se alinhem.

Definição de Aceitação do Risco

Quando uma organização toma uma decisão acerca do risco só pode fazer de 3 escolhas:

Aceitar o risco tal como foi avaliado – a organização pretende tolerar o impacto potencial de uma segurança comprometida.

Mitigar o risco – reduzir o nível de risco através de controlados melhorados até atingir um nível aceitável.

Terminar a actividade – isto implica que o risco não pode ser reduzido, até um nível aceitável, com efectividade de custo para a actividade de negócio que está a criar o risco.

A forma como estas decisões são tomadas e por quem são definidas na Política de Segurança de Informação da organização. Decisões de Ao Nível de risco podem ter de ser tomadas pela Comissão Executiva enquanto os riscos de baixo nível podem ser decididos pelo proprietário do negócio.

Em todos os casos, a decisão deve ser baseada numa avaliação formal do risco real. Sem surpresa, este processo é denominado Avaliação de Risco e é o trabalho da Segurança da Informação garantir que o risco é avaliado de forma regular.

A actividade de Avaliação de Risco

Risco = Impacto x Ameaça x Vulnerabilidade. Esta não é uma verdadeira fórmula matemática, mas é uma equação que declara que o risco é a combinação do impacto de uma perda e a capacidade de uma ameaça explorar uma vulnerabilidade.

Uma avaliação de risco abrange todos estes factores para determinar o nível de risco. Os controlos de uma organização são, também, analisados para determinar se estão adaptados à tarefa de gerir as vulnerabilidades. Há métodos quantitativos (ou seja $$) e qualitativos (por exemplo, alto, médio e baixo) para a avaliação do risco; ambos são desenhados para comunicar decisões sobre o risco.

A Ligação ao SLA

Qual é a quantidade suficiente de segurança? O negócio já tomou esta decisão na sua aceitação formal do risco. A um nível prático, O Service Level Agreement (SLA) pode referir-se ou às Política de Aceitação do Risco, ou defini-la com mais detalhe para um serviço particular em questão.

Muitas vezes o SLA documenta a frequência com que a avaliação de risco deve ser realizada e define o proprietário do negócio que está apto para tomar as decisões acerca do risco e até que nível. Pode ainda definir os níveis de risco para os quais as decisões devem ser delegadas para outras pessoas. Um SLA deve produzir investimentos de TI com custos justificáveis e o processo de aceitação de risco produz automaticamente investimentos de custos justificáveis em controlos de segurança.

Conclusão

A segurança da informação assumiu uma muito maior importância para as organizações nestes anos recentes devido à regulação, confiança nos sistemas e às preocupações dos clientes e empregados. Isto deveria reflectir-se em decisões sobre o risco pelos proprietários do negócio que directamente podem experimentar a perda potencial.

Mas, neste pequeno paìs da Europa, parece que nada pode acontecer e, portanto, gastar recursos e tempo na avaliação de risco é uma opção de segunda prioridade.

Quando o projecto corre mal

Estava tudo a correr suavemente e bem quando, de repente, verifica que está atrasado e acima do orçamento e sem fim à vista. Para voltar ao caminho necessita cumprir um processo. Proponho-lhe 8 passos neste processo.

1. Avaliação:

A primeira coisa que tem de fazer é pesquisar até que ponto está fora do caminho. Exactamente, quantos dias está atrasado relativamente ao planeado e o que é isso em % da linha de tempo? Também, quanto está acima do orçamento e o que significa isso em % do orçamento global?

2. Re-planear:

De seguida reveja o seu Plano do Projecto, para verificar se consegue recuperar tempo através de mudanças nas atribuições das actividades. Primeiro, veja se pode realocar pessoas a actividades de forma mais expedita poupando tempo. Em seguida, verifique as dependências das actividades e veja se há uma sequência mais lógica que consiga completar mais cedo os prazos. Assegure-se que identifica o caminho crítico no seu plano para que saiba que actividades devem ser concluídas e quais são secundárias. Assim, atribua os seus melhores recursos às actividades críticas e tente concluí-las mais cedo. Todo o tempo que consiga poupar através do replaneamento vai-lhe ser precioso.

3. Brainstorm:

Reúna-se com a sua equipa e reveja o plano replaneado e verifique se em conjunto conseguem obter novas ideias para realizar o projecto mais cedo ou poupar no orçamento. Pode até ficar surpreendido com os resultados que obtém.

4. Diminuir o âmbito:

A forma mais fácil de voltar a colocar o projecto no caminho certo é diminuir o âmbito. Isto significa realizar menos que o previsto originalmente. Faça uma lista dos resultados do seu projecto, priorize-os em relação com os objectivos do projecto e veja se há alguns resultados que possa, com a autorização do Sponsor do Projecto, remover do âmbito do projecto, para o ajudar a voltar ao caminho. Não significa que estes resultados deixam de ser produzidos, antes que poderão vir a ser feitos como actividades isoladas após a conclusão do projecto.

5. Peça ajuda:

Se o seu Sponsor não pretende alterar o âmbito do projecto, então peça-lhe por uma extensão do prazo ou por mais orçamento para que possa atribuir mais recursos para concluir dentro do prazo. Obtenha o seu apoio informando-os do seu atraso. Seja honesto e frontal. Mostre que está disposto a fazer tudo para estar em condições de cumprir o prazo estabelecido, mas que necessita de apoio para isso. Com este apoio tudo é possível.

6. Controle a mudança:

Agora tem de controlar de forma apertada a mudança para que novas funcionalidades ou resultados não sejam adicionadas sem a sua aprovação. A mudança é comum na maioria dos projectos o que o obriga a controlá-la para garantir a oportunidade de sucesso.

7. Reunião:

Realize uma reunião com a equipa para explicar porque é que o projecto está atrasado e a importância dele. Obtenha o apoio deles para trabalharem com empenho e mais horas de forma a serem capazes de o realizar em tempo. Lembre-se que necessita da compreensão de todos e adesão para poder acabar em tempo e dentro do orçamento.

8. Comunique:

Mantenha todos informados do progresso com regularidade. Desta forma manter-se-ão focados e motivados para alcançar os objectivos estabelecidos.

Compreender o Workflow ITIL

Muitas companhias começam a sua implementação ITIL com a função Service Desk e os processos de Gestão de Incidente e Problema. O seguinte exemplo mostra como estes grupos podem trabalhar em conjunto.

Call Center – o Serviço de Call Center redirecciona as chamadas para o apropriado Service Desk ou membro do Service Desk com base nos atributos da chamada. Por exemplo, um utilizador requer assistência na utilização de uma aplicação. Esta chamada é redireccionada pelo Call Center para o agente apropriado no Service Desk.

Service Desk – O agente do Service Desk toma a propriedade do Incidente. Regista o Incidente em preparação de realizar suporte directo ao utilizador, este membro do Service Desk de forma segura realiza as actividades estabelecidas no processo de Gestão de Incidente.

Gestão de Incidente – O agente, torna-se um operador de Incidente no âmbito do processo de Gestão de Incidentes, recolhe a informação e tenta verificar a triagem com o utilizador. Se o agente for incapaz de assistir o utilizador, pode escalar ou abrir um registo de Problema.

Escalar o Incidente

A Escalação é outro ponto de confusão em muitas organizações que planeiam para ITIL. Quando o primeiro nível de tratamento esgota todas as fontes de informação disponíveis e determina que é provável que não seja capaz de concluir dentro da linha de tempo ou é-lhe impossível assistir o utilizador, então o Incidente deve ser encaminhado para outra pessoa (2º nível) ou aberto um Problema.

Assumindo encaminhamento do Incidente para um 2º nível, o agente continua a desempenhar actividades na base da Gestão de Incidentes. A pessoa do 2º nível de Incidente pode residir fisicamente em qualquer sítio, seja num departamento de TI ou mesmo fora da organização, mas desde que trabalhe sobre o Incidente, estará a trabalhar na dependência e controlo da Gestão de Incidentes.

Não há nenhum requisito de que qualquer nível de suporte para além do agente do Service Desk (p. ex. 2º, 3º, etc.) faça parte de qualquer função ou departamento e qualquer linha de suporte pode realizar investigações talvez até com a utilização de procedimentos de teste, ferramentas de diagnóstico, etc.

Como exemplo, na dependência de um Incidente, o segundo nível poderá ser um técnico no grupo de redes ou um administrador que trabalha no departamento de comunicações. É o trabalho realizado, não a estrutura de reporting organizacional que interessa. Isto exige muitas vezes a existência de Acordos de Nível Operacional (OLA – Operational Level Agreements) entre as TI e vários processos, bem como grupos funcionais.

No nosso exemplo continua a ser a rotina do trabalho do dia-a-dia e considerado, contudo, um Incidente. Se o segundo nível determina que não é provável solucionar ou é incapaz de resolver a questão, pode então ser escalado. O número de níveis de suporte é indefinido, sendo único para cada infra-estrutura da companhia ou organização. Não é incomum existirem dois, três ou quatro níveis de Suporte a Incidentes cada um com crescente foco em conhecimento e experiência.

Gestão de Problemas

Em qualquer momento, se parece que a questão é tão complexa ou que exige o envolvimento de múltiplos departamentos tecnológicos ou silos, o Incidente pode exigir a criação de um registo de Problema. Algumas organizações escolhem levantar um Problema sempre que um Incidente não possa ser encontrado na Base de Conhecimento.

Quando trabalha com um Registo de Problema, a equipa passa a trabalhar sob o controlo do processo de Gestão de Problemas. Este exige a nomeação de um “Gestor de Problemas” ou um “Coordenador de Problemas” para liderar o trabalho e supervisionar as interacções entre departamentos.

È neste ponto que é formada uma “equipa de Problema” de técnicos de vários grupos técnicos. Os técnicos do Service Desk (que realizam o suporte de 1º nível no tratamento de Incidentes) tomam agora a responsabilidade de supervisão e monitorização da resolução do Problema, coordenando com o líder da equipa de problema e mantendo o utilizador ou cliente informado conforme for requerido.

Sumário

Precisamente são estas funções e as suas responsabilidades que criam o processo. Como pudemos ver nestes exemplos, a estruturação para os processos nem sempre exige a reorganização dos departamentos. Mas exige muitas vezes formação e organização de equipas dinâmicas para que saibam como e quando devem actuar (por exemplo, Utilização de Scripts para a Gestão de Incidentes) e podem, ainda exigir Acordos de Nível Organizacionais.

Processos e Performance

A estrutura organizacional tem um papel significativo no sucesso ou fracasso da adopção da ITIL. Uma correcta estrutura organizacional é crítica para o seu sucesso … mas provavelmente não deverá reorganizar para a alcançar.
Embora muitos líderes percebam que a estrutura organizacional afecta a capacidade das TI de obter a performance exigida, já muitas vezes ficam confundidos quando as alterações efectuadas para esse efeito não devolvem os resultados esperados.
Em 2006, a Gartner previu que 45% dos realinhamentos organizacionais das TI iriam falhar devido à confusão entre processo e performance. Esta confusão acerca da estrutura, por sua vez, gera resistência dentro das organizações. No mesmo ano de 2006, um estudo realizado sobre as barreiras para a adopção da ITIL encontrou 72% das resposta a apontar para a resistência organizacional.
A tentativa de mapear os processos ITIL de forma funcional, ou seja um grupo de Incidentes, um grupo de Problemas, e por aí fora, rapidamente verifica-se problemático. Os processos descrevem o trabalho realizado por pessoas, não as estruturas organizacionais.

Processo vs. Performance

A estrutura organizacional tradicional das TI faz pouca distinção entre processo (descrição das actividades) e performance (execução das actividades.
A estrutura tradicional das TI é baseada num silo, com a especialização técnica concentrada em unidades organizacionais auto-contidas. Esta estrutura em silo é uma herança das operações de TI iniciais, que coleccionavam a tecnologia os seus tecnólogos em unidades geríveis.
Por exemplo, o departamento de telefones operava os sistemas de telefones, forneciam suporte aos utilizadores e realizavam a manutenção dos sistemas. O departamento do mainframe faz o mesmo, bem como o departamento de redes, etc. Cada silo tem as suas próprias versões de processos similares e não há nunca muita coordenação entre estes silos.
Não há nada de errado com a existência de silos e eles existem na maioria das organizações e profissões. A utilização de silos é usada para coleccionar especialistas em unidades geríveis.
Contudo, enquanto o âmbito das TI expandiu-se muito para além de sistemas isolados e desligados, a gestão em silo não acompanhou o progresso. Os serviços de TI dos nossos dias são sistemas complexos de comunicação e colaboração atravessando múltiplos silos. Esta expansão dos serviços de TI é a causa do dilema com que nos defrontamos para uma operação orientada aos processos.
Para visualizar uma organização efectiva a utilizar operação dirigida ao processo com equipas dinâmicas compostas por recursos provenientes de localizações variadas, considere a forma como opera tipicamente um quartel de bombeiros:

1. Os seus membros realizam os seus empregos regulares até que ouvem o alarme de incêndio; nessa altura reúnem-se no quartel.
   
2. Cada bombeiro conhece a sua função – um toma o comando, outro dá o arranque do carro e outros recolhem e carregam as ferramentas.
   
3. Todos conhecem o seu trabalho e não há confusão acerca de quem é que faz o quê, quando, como ou porquê.
   
4. A trabalhar em conjunto apagam o fogo.
   
5. Quando o fogo está extinto, regressam ao quartel para limpar o equipamento e completar a documentação.
   
6. Então regressam aos seus empregos e esperam por nova chamada.

Embora seja inevitável alguma mudança organizacional para suportar as TI modernas, a verdadeira mudança não está onde se sentam os técnicos de TI ou a quem eles reportam. A mudança real é em como eles se organizam dinamicamente e colaboram para alcançar um objectivo – tal como a analogia dos bombeiros voluntários.
Ver mais em How to Organize ITIL

Ciclo da Vida de uma EQUIPA

Na passada semana falámos da criação e funcionamento de uma equipa e apresentámos um ciclo de vida para a equipa. Um ciclo de desenvolvimento e funcionamento. Hoje vamos desenvolvê-lo.
Muitos irão identificar-se com processos em que estão ou estiveram envolvidos, o que é importante. É uma abordagem de discussão. O ciclo compõe-se de:

• Formação
  
• Discussão
  
• Normalização
  
• Realização
  
• Desmobilização

Reunião

Todas as equipas recentemente criadas passam por uma fase inicial de «tomada de conhecimento». Durante esta fase, a equipa e os seus membros evitam questões sérias e sentimentos e focam-se nos itens de rotina, como apresentações da equipa, quem faz o quê, quando são as reuniões, etc. A equipa depende muito do seu líder para orientação e direcção e este sente que está sempre a responder a perguntas acerca dos propósitos, objectivos e relações externas da equipa.

• Esta é uma fase confortável, mas ao evitarem-se os conflitos e ameaças não se faz, de facto, muito. Uma equipa que se mantém nesta fase demasiado tempo pode nunca conseguir a daí sair para enfrentar a actividade para a qual foi criada.

Discussão

Conforme a equipa vai saindo da face inicial de Reunião, começa a enfrentar as questões importantes e os primeiros confrontos começam a acontecer. Durante esta fase, os membros da equipa podem alterar de posição conforme tentam estabelecer-se em relação com os outros membros da equipa e com o líder. Pode mesmo vir a desafiar o líder. Facções e cliques podem formar-se e podem acontecer lutas pelo poder.

• Alguns membros podem comentar que é bom começar a entrar nas questões reais, enquanto outros irão querer permanecer no conforto e segurança da fase de Reunião. Mesmo quando os conflitos visíveis foram suprimidos, eles continuam lá, só que estão abaixo da superfície.

Nesta fase o líder apoia os membros individuais e foca a equipa nos seus objectivos. Tenta construir a transparência em volta do propósito da equipa para garantir que os membros compreendem as questões e problemas e que a equipa evita as distracções das questões emocionais e de relação.
Uma equipa que se mantém demasiado tempo na fase de Discussão irá gastar tempo precioso a solucionar conflitos entre os seus membros, mas falhará em enfrentar as actividades de que está encarregada.

Normalização

Quando a equipa progride para a fase de Normalização na realidade afirma o estabelecimento e aceitação das regras de funcionamento do grupo e o âmbito das suas actividades e responsabilidades.
Tendo ultrapassado as discussões, agora todos os membros do grupo compreendem e aceitam-se uns aos outros e apreciam as competências, experiência, funções e responsabilidades de cada um. As pessoas ouvem-se, apreciam-se e apoiam-se uns aos outros e estão Até preparados para alterar alguns preconceitos. A equipa acorda com facilidade nas grandes decisões e com conforto delega as decisões menores a indivíduos ou pequenas equipas dentro do grupo.
A equipa trabalha como um grupo em todos os aspectos e mantém um respeito geral relativamente ao líder que desempenha uma função de facilitação e apoio. O compromisso e a unidade são fortes e a equipa consegue envolver-se em actividades sociais e de diversão. Contudo, o líder deve continuar atento pois a equipa ainda é frágil. Os seus membros trabalharam muito para alcançar este nível e podem até resistir a qualquer pressão para mudar – especialmente de fora – por receio de que a força do grupo se quebre ou recue para a fase de Discussão.
O desenvolvimento a partir desta fase e o movimento para a fase de Realização, permitirá posicionar a equipa como uma entidade verdadeiramente performante.

Realização

Nem todos os grupos alcançam a fase de Realização, na qual o grupo mostra interdependência bem como flexibilidade. Todos conhecem os outros suficientemente bem para serem capazes de trabalhar em conjunto e confiar o suficiente para permitir actividade independente. Este alto grau de conforto significa que o grupo pode dirigir todas as suas energias em direcção às actividades em mãos. O grupo, consciente da estratégia, sabe claramente porque é que está a fazer o projecto. A equipa partilha uma visão e pode manter-se em pé sem necessidade de interferência ou participação do líder.
Irão continuar a ocorrer desavenças, mas a equipa soluciona-as positivamente, fazendo as alterações necessárias aos processos e estrutura. Ao mesmo tempo que trabalha para atingir o seu objectivo, a equipa também se envolve nas questões de relações, estilo e processos. Os seus membros são todos da mesma forma orientados às actividades e às pessoas.
O líder de uma equipa de Realização delega e acompanha, ao mesmo tempo que algumas vezes assiste os membros da equipa em questões de desenvolvimento pessoal e interpessoal.

Desmobilização

Finalmente, independentemente do nível alcançado pela equipa terá de enfrentar os desafios da Desmobilização, quer das actividades como dos restantes membros da equipa. Isto é mesmo verdade quando se tratam de grupos de projecto quando a equipa é descomposta no final. Os indivíduos atravessam um momento de perda.
Muitas equipas sublinham esta fase com uma cerimónia formal de fecho. Os indivíduos sentem-se orgulhosos das suas realizações e do grupo e felizes de terem participado em tal grupo. A fase de Desmobilização ajuda ao reconhecimento daquilo que foi realizado e de forma consciente partirem.

Manter a Dinâmica de Construção

Uma equipa envolve muita gente numa organização e a responsabilidade para construir uma equipa efectiva e produtiva estende-se bem para além do papel do líder nominal da equipa. De facto, assenta sim e solidamente nos pés de cada membro.
LQ

O que é que tem a EQUIPA?

Quais são as características gerais e comuns de uma equipa produtiva. A primeira é que a equipa tem um propósito. A equipa pretende completar um projecto identificado em tempo e dentro do orçamento.

• Uma equipa requer um conjunto de diferentes competências e talentos. Os jogadores de futebol assumem posições e respondem com os seus talentos e competências individuais para jogarem bem nessas posições. As equipas de trabalho vêm de diferentes departamentos e disciplinas e trazem para a equipa o seu valioso conhecimento e competências nessas áreas.
• A equipa continua a existir quando perde um dos seus membros ou alguém está indisposto. A equipa tem reservas e tem um plano para dar «cobertura» a cada membro quando ocorre uma situação destas.
• A equipa tem um líder. As equipas de futebol têm treinadores e as equipas de trabalho têm gestores. Eles ajudam a estabelecer a direcção e coordenam os esforços dos membros da equipa.
• A equipa é maior do que a contribuição individual de qualquer membro. Não interessa o enorme talento e conhecimento que um indivíduo possua, precisamos de toda a equipa para jogar o jogo e marcar golo.

Ciclo de Vida de uma Equipa

As equipas são um grupo e registam como tal diferentes formas de eficiência e efectividade. Para o seu desenvolvimento um processo geral que pode ser definido em passos até alcançar uma posição totalmente funcional.

• Formação
• Discussão
• Normalização
• Realização
• Desmobilização

Manter a Dinâmica de Construção

Uma equipa envolve muita gente numa organização e a responsabilidade para construir uma equipa efectiva e produtiva estende-se bem para além do papel do líder nominal da equipa. De facto, assenta sim e solidamente nos pés de cada membro.
No próximo post analisaremos as diversas etapas do ciclo de vida da equipa e vão ver como se identificam com elas.
LQ

Como acompanhar os Projectos

Acompanhar com regularidade um projecto é o desafio mais difícil; gerir pessoas, equipamento, tempo, dinheiro e materiais para concluir o seu projecto a tempo. Para realizar isto com sucesso, é necessário manter debaixo de olho 5 áreas do seu projecto…

1. Tempo e Custo

Reserve uma hora por semana para determinar se continua em condições de terminar o projecto em tempo. Para fazer isto, identifique todas as actividades que estão a ficar atrasadas e determine se elas podem provocar um atraso a todo o projecto. Em seguida, procure formas de poupar tempo através de conclusão de actividades mais cedo, atraso de actividades não críticas ou com a obtenção da aprovação do Sponsor para remover actividades desnecessárias.
Pode ainda ter de rever a despesa total do projecto até à data em relação ao orçamento original estabelecido. Identificar formas de reduzir os custos alocando recursos menos dispendiosos, com a redução do âmbito do projecto ou com o incremento da eficiência da equipa.

2. Atribuição de Recursos

Tem de ter uma atitude de constante acompanhamento da percentagem de tempo que a sua equipa está atribuída às actividades. Se tem pessoas atribuídas a actividades 50% do seu tempo e depois a 150%, então provavelmente não está a trabalhar com eficiência. Perlo contrário, deve balancear com justeza a carga de trabalho da equipa para os manter ocupados 80-100% do seu tempo, sem estarem sobrecarregados. Se quiser carregar um recurso, faço-o por um período curto para evitar que este fique esgotado.
Conforme vai reatribuindo o trabalho entre os seus recursos, deve estar atento ao nível global de aplicação dos recursos. Pode estar a acontecer que todos estejam sub-alocados e que possa retirar uma pessoa do projecto com ganhos de custo. Por outro lado, se todos estão sobre-alocados então necessita com rapidez de alocar mais recursos.

3. Progresso e Eficiência

É necessário acompanhar o progresso e a eficiência da equipa. ‘Progresso’ significa a percentagem de actividades concluídas até à data. ‘Eficiência’ significa o número de actividades concluídas dentro do prazo. Precisa de acompanhar estes itens para garantir que estamos a progredir de acordo com o plano e que a sua equipa está a trabalhar com eficiência e a concluir as actividades que lhe estão atribuídas.

4. Riscos, Alterações, Questões

Todos os projectos se defrontam com riscos, mudanças e problemas em algum ponto no caminho. Muitas vezes é impossível impedir que ocorram, assim o truque é resolvê-los o mais depressa possível quando ocorrem. Durante o ciclo de vida do projecto devemos, observá-los de perto. Para cada questão levantada deve ser estabelecida uma ‘data prevista de resolução’ e acompanhar com cuidado estas datas para garantir que conseguimos cumpri-las.

5. Saúde do Projecto

Para além de acompanhar o projecto ao nível mais micro é, também necessário afastarmo-nos para olhar o projecto de fora como se o observássemos do ar, a funcionar no seu ambiente. Temos de ter uma visão clara da saúde global do projecto. A maior parte do trabalho foi já realizada pelo acompanhamento do tempo, custo, recursos, progresso e eficiência. Mas através de uma visão sumarizada do projecto em cada semana é possível liderar a equipa do projecto para o sucesso.

Realizar um estudo de viabilidade

A melhor forma de saber se o seu projecto é realizável é completar um Estudo da sua Viabilidade. Este é um processo que ajuda a criar a confiança que a solução que é necessária construir pode ser implementada em tempo e dentro do orçamento.

Um estudo de viabilidade deve ser completado tão cedo quanto o possível dentro do ciclo de vida do projecto. A melhor ocasião é quando forem identificadas várias soluções alternativas e é necessário conhecer qual a solução que é mais viável de implementar. Vamos apresentar um método de o realizar…

1. Pesquise as Exigências de Negócio

Na maioria dos casos, o projecto é exigido por um problema existente no negócio. Estes problemas são exigências do negócio (em inglês aparecem como business drivers, palavra já aceite na língua portuguesa). Precisamos de ter uma compreensão clara do que são estas exigências como parte do Estudo de Viabilidade.

Por exemplo, a exigência pode ser pela actualização de um sistema de TI ultrapassado e que provoca queixas do cliente ou a necessidade de fusão de dois negócios devido a uma aquisição. Independentemente da exigência em questão, o que é necessário é alcançar a questão de fundo para que se compreenda porque é que o projecto foi lançado.

Também é necessário compreender porque é que esta exigência é importante para o negócio e porque é que é crítico que o projecto realize esta solução dentro de um específico intervalo de tempo. Compreendido isto então há que avaliar qual o impacto que haverá para o negócio se o projecto for atrasado.

2. Confirme as soluções alternativas

Agora que dispomos de uma compreensão mais clara do problema de negócio que é enfrentado pelo projecto, devemos compreender e segmentar quais as soluções alternativas disponíveis.

Estas soluções devem ser analisadas e compreendidas e correlacionadas com o problema de negócio que devem solucionar.

3. Determinar a viabilidade

Assim o que temos de fazer é identificar a viabilidade de cada solução. A pergunta que deve ser feita a cada solução alternativa é «será que podemos realizar o projecto no tempo e com o orçamento apontado?»

Para responder a esta pergunta, deveremos usar um conjunto de métodos para avaliar a viabilidade de cada solução. Eis alguns exemplos com que podemos realizar a avaliação da viabilidade:

Pesquisa: Realizar pesquisas para saber se outras companhias implementaram as mesmas soluções e como funcionam.

Prototipagem: Identificar a parte da solução que possui o risco mais elevado e construir um modelo para saber se é possível a sua criação.

4. Escolha a solução adequada

Conhecida a viabilidade de cada solução alternativa, o próximo passo será seleccionar a solução preferida para a realização do seu projecto. Escolha a solução que é mais viável de implementar, tem o risco menor e na qual tenha mais confiança na sua realização efectiva.

Escolheu uma solução para um conhecido problema do negócio e tem um elevado grau de confiança que pode realizar a solução dentro do tempo previsto e conforme ao orçamento definido.

5. Reavaliação

Chegou o momento de conduzir a solução escolhida para outro nível reavaliando a sua viabilidade. Assim, faça uma lista de todas as actividades que são necessárias para completar a solução e debata-as com a sua equipa para saber quanto tempo eles acham que levarão a realizá-las e concluí-las. Adicione estas tarefas e intervalos de tempo a um plano de projecto para ver se as consegue realizar até ao deadline do projecto.

De seguida, peça à sua equipa que identifique as actividades de mais alto risco e peça-lhes para investigarem mais profundamente e verificarem se são realizáveis. Utilize as técnicas do ponto 3. Para ter um maior grau de confiança na sua realização. Finalmente, documente todos os resultados num relatório de Estudo de Viabilidade.

Depois de concluir estes passos, obtenha a aprovação do seu Estudo de Viabilidade para que todos os membros da sua equipa tenham o mais alto nível de confiança na possibilidade de concretização do Projecto.

Melhoria do processo de comunicação

A comunicação em projecto é dos factores decisivos para o sucesso das actividades e a obtenção de, por um lado, compromisso de gestão e, por outro, motivação da equipa e participantes.

Estou certo de que não é necessário convencer ninguém da importância de uma boa comunicação. As competências de comunicação são afloradas em praticamente todas as descrições de funções para qualquer posto de trabalho em qualquer nível das organizações. 

A comunicação em projecto passa por 3 fases de processo distintas: Desenho, Implementação e Gestão. Destas três, na minha opinião, devemos despender mais tempo na fase de Implementação do Processo porque é, em primeiro, a fase mais subestimada e, em segundo, porque é aquela em que é mais fácil serem introduzidos erros.

Em outras ocasiões, tenho sublinhado a importância de, em gestão de projecto como em outras áreas, ser desenvolvida a evidência de gestão da mudança organizacional com saliência para os seus dois componentes principais: Comunicação e Formação.

Sublinho sempre que a Comunicação é muito mais do que “enviar emails” e, por isso, insisto em que a comunicação é muito mais do que uma comunicação de «dois sentidos». Porque não, então, um modelo de comunicação assente em «4 fases»? E quais são elas:

1. Dizer / enviar a mensagem

2. Validar que a mensagem foi recebida.

3. Validar que a mensagem foi compreendida.

4. Validar que a mensagem foi aceite.

Não é suficiente só dizer ou enviar a mensagem e então assumir, bem assumir tudo. O remetente deve realizar os passos que lhe garantem que a mensagem foi mesmo recebida. E, mesmo se a mensagem foi recebida, pode ser necessário que seja compreendida. Finalmente, mesmo de a mensagem é compreendida, pode haver mal entendidos evitando que a mensagem seja, de facto, aceite.

A comunicação não pode ficar baseada em assumpções. A comunicação deve ser validada e isso exige algum trabalho e seguimento.

Embora seja provável que perceba porque não sugiro estas tácticas para a minha cara-metade, julgo que esta é uma abordagem razoável no dia-a-dia dos negócios. Penso, ainda, que é óptimo modelo para os gestores de projecto, que provavelmente dependem da comunicação mais do que quaisquer outros.

A comunicação é, hoje, essencial em todos os aspectos do sucesso das empresas, e está em questão muito mais do que só uma chávena de café.

Luís Quintino

O que é a WBS?

 

Esta coisa da Gestão de Projectos de que toda a gente acha que sabe alguma coisa, senão tudo, e que é reduzida à expressão «isso é feito com o Project», como se um programa de computador fosse equivalente a uma metodologia de conhecimento, é muito mais complexa. No nosso mercado, estes conhecimentos têm muitas lacunas e mesmo o completo desconhecimento quando se trata de ferramentas de pensamento essenciais para planear de forma adequada. Hoje vamos tentar responder à pergunta o que é a WBS?

Uma WBS (Work Breakdown Structure) ou Estrutura de Decomposição do Trabalho representa de forma consistente as actividades de topo requeridas para concluir o projecto. O foco desta WBS pode ser quer o Produto (resultado) quer o projecto, ou ambos. Os elementos da WBS são numerados usualmente e este sistema de numeração pode ser organizado de diferentes formas. O propósito primário de uma WBS é desenvolver ou criar conjuntos pequenos e geríveis de trabalho denominados Work Packages.

Assim a WBS

• Serve como plano base do âmbito do projecto
• É uma das mais importantes ferramentas de gestão de projecto
• Está na base do planeamento, estimação e controlo do projecto
• Permite visualizar todo o projecto
• Sublinha que trabalho NÃO incluído na WBS NÃO faz parte do projecto
• Reforça a adesão da equipa ao projecto
• Serve de mecanismo de controlo para manter o projecto na data prevista
• Permite estimativas mais exactas de custo e tempo
• Serve de redutor do derrapar do âmbito do projecto

A WBS não deve ser confundida com::

• A OBS ou Estrutura de Decomposição Organizacional
• Lista de Materiais
• Estrutura de Decomposição do Risco
• Structure de Decomposição dos Recursos

Esta ferramenta está relacionada directamente com o agendamento de um projecto. No fundo, é uma decomposição funcional das actividades de um projecto, em que o trabalho total do projecto é sucessivamente decomposto em subtarefas. Começa pelo objectivo final a atingir e requerido e sucessivamente subdividindo em componentes geríveis em termos de dimensão e complexidade, desta forma por exemplo: programa, projecto, sistema, subsistema, componentes, actividades, sub-actividades e elementos de trabalho.

Dicionário da WBS

Quando a WBS construída é extensa ou se as categorias do seu conteúdo não são óbvias, para os membros da equipa de projecto, pode ser útil escrever um Dicionário da WBS. Este documento irá descrever cada elemento da WBS e pode ainda dizer o que não é um elemento.

Os benefícios de utilizar uma WBS são:

• Reforço da equipa de projecto em torno de um mapa único do trabalho
• Oferece uma estrutura para identificar os projectos separadamente das organizações, sistemas de custos, fontes de financiamento
• Clarifica as responsabilidades
• Concentra o foco do projecto nos seus objectivos
• Força um planeamento detalhado e a respectiva documentação
• Identifica Work Packages específicos para a respectiva estimação e alocação de trabalho.

A Work Breakdown Structure (WBS) é um ponto central no esforço de planeamento do projecto. Não é possível desenvolver um realístico plano para um projecto sem primeiro se desenvolver uma WBS que será detalhada o suficiente para permitir uma significativa identificação de todas as actividades do projecto que devem ser concluídas. O processo de criação de uma WBS é muito importante, porque durante este processo de decomposição do projecto, o gestor do projecto e a equipa, bem como todos os gestores funcionais envolvidos são forçados a pensar acerca de todos os aspectos do projecto.

Resultados específicos da WBS

Uma WBS é uma técnica de decomposição de um projecto nos seus elementos constituintes. As actividades mais pequenas, denominadas Work Packages, devem ser identificadas como unidades geríveis que podem ser planeadas, orçamentadas, agendadas e controladas. A WBS indica a relação entre a estrutura organizacional e os objectivos do projecto e as suas unidades e dessa forma oferece uma base firme para planear e controlar o projecto.

A WBS deve ser orientada ao produto ou orientada à actividadem e deverá incluir todo o esforço necessário, que deve ser levado a cabo para atingir o objectivo final. Porque ela identifica o trabalho exigido para alcançar um objectivo ela ajuda a identificar os interfaces necessários e desta forma é muito útil em projectos complexos. Contudo, tem uma limitação importante, ela não mostra o tempo das actividades o que implica a utilização de outras ferramentas.

Luís Quintino

Processos que apoiam o sucesso em projecto (Parte 2)

Na semana passada vimos que, apesar de estar convencido que os fracassos em projectos resultam de pobre Gestão de Projecto e Portfólio – ou mesmo a total ausência desses processos, há um conjunto de coisas que podem ser feitas para melhorar as oportunidades de sucesso. Falámos então do papel do Sponsor do projecto e da melhoria na Definição do Projecto.

Hoje continuamos com:

Desatenção ao Processo de Mudança do Negócio

Esta é a raiz de muitos fracassos em projecto, designadamente na área das TI. O foco de muitos projectos é muitas vezes colocado na transformação tecnológica e é dada muito pouca atenção ao impacto da mudança e à necessidade de acompanhar esta como um processo de negócio. O Gestor de Projecto consegue criar as novas funcionalidades mas o valor e os benefícios não são muitas vezes compreendidos e, em virtude disso, demoram a ser usados.

As alterações de processos de negócio necessitam de uma compreensão e execução de gestão de processo e de gestão organizacional, que são disciplinas essenciais à transformação do comportamento humano. A Fase de Definição do Projecto deve determinar se estas mudanças de processos de negócio se localizam dentro ou fora do âmbito do projecto.

Desconhecer qual o Factor de Sucesso que é mais importante: Tempo, Custo ou Performance.

Como já vimos, as razões directas de fracasso dos projectos são diversas. O projecto pode estar atrasado, acima do orçamento e abaixo na performance. Na gestão de projecto costuma dizer-se: custo, tempo ou performance, escolha uma de duas. Os gestores de projecto devem saber qual destes Factores de Sucesso do Projecto é mais crítico. O Sponsor do Projecto deve trabalhar com a Administração para atingir um consenso sobre a máxima prioridade e gerir o projecto em conformidade.

Pobre comunicação

A comunicação pobre é uma fraqueza dos projectos. Todos os Gestores de Projecto devem desenvolver e manter um Plano de Comunicação de Projecto formal, bem pensado e completo. Um gestor de projecto deve saber quem necessita de que informação e quando e como será essa informação fornecida. Isto exige aos Gestores de Projecto não só que compreendam as decisões exigidas para governar os projectos até à sua conclusão com sucesso, mas também devem mapear estas decisões aos dados requeridos para garantir que estas são correctas e racionais. A outra dimensão para ultrapassar as pobres comunicações é a necessidade essencial para os Gestores de Projecto para fornecerem dados exactos, tão rápido quanto possível. Procedendo desta forma, os Gestores de Projecto devem evitar, ou melhor ultrapassar, qualquer impulso para esconder más notícias ou diminuir riscos ou problemas.

Processo ou Metodologia impróprios

Alguns Projectos falham tão só porque não possuem um processo e metodologia adequada de gestão de projecto. Isto não ocorre unicamente quando não é aplicada nenhuma metodologia, Os fracassos podem também ocorrer quando são impostos demasiados processos à equipa de projecto. Os gestores de projecto devem possuir uma compreensão elevada sobre processos e metodologias provadas na prática. Esta compreensão é essencial para aplicar o «tempero» correcto de metodologia de gestão de projecto e para lutar pela manutenção do equilíbrio delicado entre demasiado ou pouco processo.

O que acha? Julga que tratei destas questões mais gerais dos factores que contribuem para o fracasso dos projectos? Julga que há mais? Quais?

Processos que apoiam o sucesso em projecto

Recentemente numa sessão de formação em Gestão de Projecto um participante levantou o problema do insucesso em projecto sugerindo a necessidade de aprofundamento do estudo das principais causas objectivas desse facto. Os fracassos assentam em erros, mas eu acredito que estes fracassos nos projectos resultam de pobre Gestão de Projecto e Portfólio – ou mesmo a total ausência desses processos.

Há, entretanto, algumas coisas que podem ser feitas para melhorar de forma drástica as oportunidades de sucesso dos projectos.

Sponsor do Projecto

A maioria dos projectos são hoje encomendas que são acompanhadas pelos clientes através da nomeação de um responsável – o sponsor.

A falta de empenhamento apropriado do Sponsor do Projecto pode destruir qualquer projecto. Para além de fornecer a potência que permite ultrapassar as questões e riscos que ameaçam inevitavelmente todos os projectos, os Sponsors do Projecto oferecem uma ligação directa com a Liderança e Estratégia Corporativa.

Estudos recentes comprovam que quanto mais eficaz for esta ligação à estratégia de negócio mais eficaz será o progresso. Ao contrário, uma ligação quanto mais ténue for a ligação entre o projecto e a estratégia, mais desafios serão encontrados pelo projecto. Os Sponsors devem ainda assumir o controlo de performance do projecto para garantir que este se mantenha no curso certo para cumprir os objectivos da estratégia – monitorizando simultaneamente a performance de projecto e a direcção estratégia corporativa (que pode ser mudada durante o decurso do projecto).

Definição pobre do projecto

Os projectos mal definidos estão amaldiçoados à partida. É imperativo que todos os projectos possuam objectivos de negócio e técnicos concretos e uma compreensão exacta e descrição do que se vai realizar com eles. Nada garante melhor que os projectos são correctamente definidos do que o cumprimento de um confiável processo de caso de negócio do projecto – em Portugal seria denominado um estudo de viabilidade – e um processo de definição de charter do projecto (o mapa das estradas para guiar o projecto) para ser seguido «religiosamente» por todos os envolvidos.

Este Caso de Negócio do projecto confiável fornecerá os dados necessários para determinar não só se o projecto deverá ser realizado mas também se poderá ser feito. Logo que aprovado este Caso de Negócio um compreensivo Charter do Projecto irá descrever o Quem, Quê, Onde e Quando do projecto. Então o que deverá ser incluído neste Caso de Negócio? Algumas sugestões de elementos frequentemente não incluídos ou não respondidos nos casos de negócio, como:

Os benefícios de negócio que são alvo e o seu alinhamento com a estratégia de negócio – quem do negócio ficará responsável por os garantir.

• As mudanças no negócio necessárias para criar um valor adicional
• Os investimentos necessários para fazer as mudanças de negócio
• Os investimentos requeridos para mudar e adicionar novos serviços, bens ou produtos
• Os custos de negócio para operar da forma alterada
• Os riscos inerentes em todos os referidos acima incluindo quaisquer constrangimentos ou dependências
• Quem terá de prestar contas pela criação com sucesso do novo valor óptimo
• Como serão monitorizados o investimento e a criação de valor através de todo o seu ciclo económico e quais as métricas utilizadas.

(Elementos retirados do Business Case da Val IT Framework)

(continua)

Gestão dos Problemas da Equipa

Bloqueio e negação estão entre os problemas mais comuns em muitos projectos.

Estes fenómenos relacionam-se com os graus insuficientes de consenso entre os participantes numa equipa de projecto. Esta falta de comunicação, já que é disso que se trata, é um dos maiores obstáculos ao sucesso.

Sem um consenso suficiente em questões importantes de projecto ocorrem muitas vezes dois problemas:

• Bloqueio: o progresso do projecto pára, por falta de consenso ou acordo nos melhores passos para avançar. Em situações de bloqueio, a equipa não alcança um acordo e as decisões de projecto tornam-se lentas ao mesmo tempo que todos discutem.
• Negação: O progresso do projecto continua, apesar da falta de consenso. Em situações de negação a equipa não enfrenta as divergências, acordando em aguardar até, em qualquer momento no futuro, resolver os problemas em aberto. Os problemas então escondem-se só para depois «inesperadamente» irromperem mais tarde, usualmente numa forma mais severa.

Face à incapacidade de obter o acordo da equipa aqueles que devem tomar as decisões ficam com poucas escolhas a não ser aceitar os atrasos do projecto no presente, ou ignorar os problemas diferindo as soluções para o futuro. Estas atitudes tornam-se assim as causas de muitos fracassos em projecto.

Estes problemas de comunicação minam o nível saudável de colaboração que a equipa deve possuir e conduzem a falhanços. Não há uma fórmula mágica para resolver e4stes problemas, que estão profundamente enraizados na cultura e hábitos da forma como as equipas trabalham em conjunto.

Dito isto, sugiro criar uma atitude atenta e cuidadosa às reuniões da equipa em que se apresentem questões de difícil consenso. Para agir sobre as questões, procure um caminho que faça agregar os propósitos e expectativas dos participantes do projecto. Esta opção pode envolver reuniões privadas, discussões de grupo ou talvez até uma combinação de poções mágicas e muita sorte. Independentemente do método utilizado é crucial a demonstração das expectativas dos departamentos ou silos de informação.

Não há nenhuma organização que esteja imune ao bloqueio e negação. O reconhecimento deste facto oferece uma oportunidade realista de interromper os ciclos disfuncionais de colaboração que podem estar escondidos entre as «brumas» da familiaridade na participação da equipa.

Conhecer o problema é já o início da solução.

Porque não deve ir para a Gestão de Projectos?

 

Continuação. Tratámos antes das características que se relacionam mais com as capacidades de comunicação das pessoas que estão ou querem ir para Gestor de Projectos, mas que talvez não preencham mesmo as condições indispensáveis.

Ho je tratamos das preferências e gostos. Ora vejamos:

#5: Não gosta de cumprir processos

Sim, eu sei que ninguém quer ser escravo dos processos. Mas são precisos bons processos para ser efectivo, ao mesmo tempo que os seus projectos se tornam maiores. Se não quer seguir bons processos de gestão de projecto, você não vai conseguir ir longe como gestor.

#6: Você não gosta de documentar as coisas

Claro, fazer tudo com moderação. Eu não estou a propor que deva adorar documentar para ser um bom gestor de projecto. Mas também, pelo contrário, não pode odiar isso. Muitos aspectos da gestão de projecto exigem alguma documentação, incluindo os relatórios de status, planos de comunicação, alterações de âmbito e Charters de projecto.

#7: Você gosta de executar e não de planear

Quando um cliente lhe adjudica um projecto, qual é a sua primeira inclinação? Se o seu primeiro pensamento ´0e reunir uma equipa e executar o trabalho, provavelmente não tem uma estrutura de pensamento de um gestor de projecto. Se não quer gastar uma apropriada quantidade de tempo para se assegurar que compreendeu o que deve ser feito, provavelmente não está talhado para ser um gestor de projecto.

#8: Se prefere receber ordens

Se pensa que o seu trabalho é receber ordens do cliente e executá-las, pode não ser um bom gestor de projecto. Os gestores de projecto devem oferecer valor para o projecto, incluindo resistindo quando os clientes pedem coisas que não estão correctas. Se o cliente levanta um pedido que está for a do âmbito, você deve ter também de invocar o processo de gestão da mudança de âmbito. «Sim senhor, iremos fazer isso» em vez de passar pelo processo de gestão da mudança de âmbito, tornará gerir o projecto uma luta para si.

#9: Você não é organizado

Pessoas que têm pobres capacidades e técnicas de organização pessoal não dão bons gestores de projecto. Se vai gerir múltiplas pessoas ao longo de um período de tempo, deve ser bem organizado para garantir que todos e cada um está á fazer o que ele ou ela precisam de fazer para serem os mais eficientes possíveis.

#10: Se pensa que a gestão de projecto é um «peso»

Ninguém consegue sentir-se bem acerca do seu trabalho se pensa que o que realiza não adiciona valor. Os bons gestores de projecto compreendem o valor do seu trabalho, e percebem que do seu trabalho irá resultar no projecto e fará que ele seja realizado em tempo e dentro do orçamento, com uma boa experiência para o cliente e para a equipa. Se pensa que os trabalhos associados com a gestão do projecto são um peso e não um valor.

Agora pense. Se está incluído em mais do que 3 destas condições, já deve reflectir se vale mesmo a pena e se estiver em 5 ou mais fuja…

Evitar enganos em projecto

 
A melhor estratégia para tratar dos enganos é, em primeiro lugar, evitar cometê-los. Mas, quando ocorrem o que fazer para navegar em segurança através deles?

---

“Seja proactivo, não seja reactivo”, já ouviu certamente esta frase,. Esta é a atitude certa quando tratamos da forma de enfrentar enganos. Claro, que a ideia é prevenir a ocorrência de erros menores antes de tal acontecer. Mas o que devemos fazer para isso?
Os erros de que vamos tratar são somente os enganos.
Alguns conselhos

1: Aprenda com os enganos dos outros

Procure colegas ou colaboradores que estejam à vontade para partilhar a experiência tida com enganos similares. Na maioria dos casos, defronta-se com uma atitude muito abrangente e receptiva, ao contrário do que se poderia esperar. As pessoas que tiveram experiências similares querem partilhá-las e ajudar na resolução destes enganos.

2: Faça a sua própria pesquisa

Independentemente do muito que sabe, irá sempre enfrentar novos desafios numa base quase diária. Cada um destes desafios exige que aprenda alguma coisa nova. Ora antes de enfrentar cada problema ou questão nova deve fazer o seu trabalho de casa. O processo de aprendizagem por tentativa erro até podia ser aceitável há uns anos atrás, mas com os recursos disponíveis actualmente, há poucas desculpas para enganos feitos unicamente porque não se fez, de avanço, a preparação e pesquisa devidas.

3: Desenhe um plano

Não consegue chegar ao destino se não dispuser de um mapa das estradas. No desenvolvimento e gestão de projectos o mapa das estradas denomina-se plano do projecto. Quer seja formalmente realizado, com todas os procedimentos e métodos, quer informalmente, ele é necessário para se saber o que deve ser realizado, ou seja, como ir daqui até ali. Muitos dias de trabalho podem ser perdidos se não estamos a fazer o que é preciso. Quando o plano é feito da forma adequada irá ajudar-nos a manter um curso correcto.

4: Cumpra standards e use modelos

Existem muito boas razões para que os profissionais experientes usem o seu tempo para criar e publicar standards de indústria e de companhia. Estes standards recolhem as melhores práticas e os procedimentos aprendidos em anos de tentativa e erro.
Os modelos, que podem ser somente formulários predefinidos, podem ser úteis já que muito do trabalho já está feito de avanço e correspondendo a uma forma standard.

5: Comunicar e coordenar com outros

Se faz parte de uma equipa, é essencial comunicar com os outros membros da equipa para evitar redundâncias e para definir o trabalho a realizar com eles. O correio electrónico, as mensagens instantâneas, os relatórios de status de projecto e as teleconferências, entre outros meios, são formas de comunicar e colaborar com outros na sua equipa. Infelizmente, cada um destes meios está longe de ser perfeito. Pode gastar a melhor parte do dia a ler e escrever emails, participar em conference calls e a comunicar em mensagens instantâneas com os seus colegas, mas isso não é suficiente, embora seja uma parte do processo de gestão de projecto.
A ferramenta perfeita para comunicar e colaborar num ambiente de equipa ainda não foi inventada ou criada. Uma das ferramentas mais efectiva continua a ser a reunião de controlo, mas há que ter um método adequado para tratar das reuniões. O projecto pode ainda beneficiar da utilização de um plano de comunicação que garanta que todos os envolvidos – incluindo clientes e stakeholders – sejam mantidos informados dos desenvolvimentos do projecto.

Palavras finais

Uma das mais importantes lições que aprendi muito cedo na minha carreira é que um engano não é um engano senão quando mais alguém sabe dele. Quando se comete um engano e o vemos e, também, nos dedicamos a solucionar esse engano e, de alguma forma, somos capazes de evitar mais problemas e resolver as implicações, então o engano nunca existiu e nunca foi.
Pode parecer óbvio, mas os enganos devem ser mantidos para nós. Não há quase nunca nada a ganhar por dizer a outros que fizemos alguma coisa realmente estúpida. Pode afectar a nossa imagem e possivelmente arruinar a nossa carreira.
Agora se um destes enganos se torna conhecido da direcção ou de outros seus pares então há que enfrentar a situação e resolver um grande engano.
Fica para outra ocasião indicar alguns conselhos para isso.
Aprendemos sempre com os nossos enganos, mas estou certo que todos preferimos, em primeiro lugar, nunca os fazermos.

Iniciar um Projecto

 
A sua organização ou companhia discute a necessidade de realizar um projecto numa das áreas importantes e para um cliente central do negócio. Precisa de concentrar-se e preparar-se para o que é essencial para o cliente – garantir os resultados do projecto. Há alguns passos essenciais que devem ser tomados para obter este resultado.

1º Passo – Estabeleça a Visão

Tem de reunir com o Sponsor do projecto e acordar naquilo que deve ser realizado e quando. Precisa de estabelecer, o mais rápido possível, a data em que o projecto deve estar concluído. Tem de compreender porque é importante para o negócio esta data de fim e qual o impacto se for ultrapassada. Só assim saberá o que está em questão e qual a medida dos seu progresso.

2º Passo – Contrate os melhores

Boas equipas entregam bons projectos. É assim crítico que consiga contratar as melhores pessoas que puder pagar para a sua equipa. Tente pedir «emprestados» peritos que colaboram na sua organização e «peça» mais recursos financeiros para recrutar os melhores do mercado. Não se reduza a pessoas menos qualificadas que com mais facilidade pode seleccionar. Leva sempre mais tempo a seleccionar as melhores pessoas, mas estas irão obter melhores resultados em menos tempo. E serão mais fáceis de gerir.
Para contratar os melhores, deve definir bem as respectivas funções. De seguida publicite o perfil destas funções dentro e fora da organização. Realize curtas entrevistas iniciais e entreviste o maior número possível. Seleccione pelo menos 5 pessoas para uma segunda entrevista e escolha dois para uma short list, antes de definir o candidato escolhido. 

3º Passo – Defina o Âmbito

Com uma boa equipa e uma data de entrega final clarificada, o próximo passo é definir o que é que o projecto vai ter como resultados. Isto é denominado o Âmbito do Projecto e tem de ser documentado profundamente.
Faça uma relação que inclua todos os resultados do projecto e descreva-os em tanto detalhe quanto o possível. Precisa de trabalhar em conjunto com o seu cliente (ou com o negócio) no que respeita a isto, porque estes resultados devem corresponder aos requisitos e entregar os benefícios de negócio definidos previamente.

4º Passo – Determine se é Viável

Agora é preciso saber se temos condições de produzir os resultados dentro do intervalo de tempo e com os recursos disponibilizados. Em breve, precisa saber se o projecto é viável ou não.
Para determinar isto, precisa de saber quanto tempo cada resultado leva a ser produzido e quantos recursos são requeridos para isso. Depois é necessário adicionar todos os intervalos de tempo e todas as horas dos recursos e verificar se correspondem ao orçamento para os recursos e à data de conclusão do projecto. Se não for assim, então tem 3 opções: Obtenha mais tempo, obtenha mais recursos ou reduza o âmbito do projecto. É tão simples!

5º Passo – Assuma o controlo e execute

Se o projecto passa o teste de viabilidade então está pronto! Necessita agora de planear o projecto, aprová-lo e gerir o dia-a-dia.

Vamos dar uma volta à carreira

 

Se pretende dar um rumo diferente e começar uma nova carreira…

Passou o Ano Novo e quer mudar a via por onde segue a sua carreira, eis algumas ideias do que deve fazer.

1. Reveja o ponto em que se encontra

Comece por escrever o que queria com a sua carreira quando a iniciou. O que queria alcançar e quando? Quando olha para o progresso realizado até hoje e o que foi alcançado, julga que se encontra no caminho certo? Se não está, onde deveria estar hoje?

Pense também, o que está a fazer hoje e quais as partes da sua função de que gosta e as que não o realizam. Então será possível ver o que deve ser alterado.

2. Defina um objectivo

Temos, agora, de definir um objectivo a 3 anos. Um único objectivo,  porque de outra forma será muito difícil recordar o caminho a seguir. Estabeleça o objectivo como qualquer coisa de que se sinta orgulhoso de alcançar e que signifique muito para si. Torne o objectivo fácil de ser entendido, mas que seja, no entanto um desafio para ser alcançado. E quando possível faça por que possa ser medido – não subjectivo. Pode ser, por exemplo:

· Gerir um projecto de 100 milhões até 2012

· Obter a certificação como Gestor de Projecto

· Tornar-se Gestor de Programas, dirigindo vários projectos

3. Necessita de um Plano de Acção

Não é possível alcançar os objectivos se não se agir. Esta é muitas vezes a parte mais difícil. Não tem de abandonar necessariamente o seu emprego ou mudar toda a sua vida para fazer isto. Precisa, sim, de pensar acerca do que terá de fazer para alcançar o seu objectivo – e, depois, criar um plano de ataque.

Faça ma lista com as 3 coisas que necessita, cada ano, para atingir o seu objectivo. Estes 3 resultados devem ser atingíveis ou simplesmente não serão alcançados. Pode ser, por exemplo, assumir uma responsabilidade diferente, gerir projectos de maior dimensão ou melhorar o conhecimento sobre gestão de projecto.

O que quer que seja, tem de ser escrito e constituir um plano de acção sólido se estamos seriamente empenhados em atingir o nosso objectivo.

4. Agora seja consistente

Com um objectivo e um plano de acção estabelecidos, está pronto para um recomeço. Diga à sua família e amigos o que pretende alcançar. Envolva o seu chefe e obtenha o seu compromisso. Obtenha tantas pessoas quantas as necessárias para o apoiar com este propósito. Eles irão regularmente perguntar-lhe como estão as coisas a ir e isto auxiliará a mantê-lo motivado na direcção certa. Com o apoio dos amigos e da família pode-se atingir qualquer coisa na vida!

5. Trabalhe com Afinco para Atingir

A melhor forma de dar uma nova expressão à sua carreira é ultrapassar os seus desejos. Tem de constantemente alcançar mais do que aquilo que desejara. Se consegue isto, então será aquele a quem oferecem promoções, aumentos de ordenado e outros benefícios.

Para ter este sucesso tem de utilizar boas ferramentas que o ajudem a planear e controlar os seus projectos.

Reduzir Riscos em Projecto

 
Quando estamos envolvidos num projecto estamos preocupados por não entregar o projecto tarde nem para além do orçamentado, então há que tomar medidas cedo.

Começar com o pé direito

Muitos projectos começam sem uma definição sólida de qual vai ser o resultado. Assim, comece por escrever um Charter detalhado do seu projecto. Este documento estabelece a visão do projecto, os seus objectivos, âmbito e resultados. Só então saberemos o que deve ser alcançado e quando.

Torne a sua equipa responsável

Porque é que deve ombrear com toda a responsabilidade do projecto? Ao contrário, delegue a responsabilidade a cada membro da sua equipa. Diga-lhes por quais dos elementos do Project Charter eles são responsáveis pelos respectivos resultados e crie um processo de prestação de contas em que serão realizadas reuniões de revisão todas as semanas para medir o progresso.
Ver artigos anteriores sobre a gestão da equipa.

Identifique à cabeça os riscos

Realize, então, um workshop para identificar os riscos prováveis para o seu projecto. Um risco é um evento imprevisto que pode impactar negativamente o seu projecto no futuro. Exemplos de riscos são: «os nossos fornecedores podem entregar com atraso», «podemos ficar sem os materiais necessários» ou «não encontramos recursos adicionais se necessitarmos deles». Cada risco terá de ser documentado e determinada a sua probabilidade e impacto no projecto.

Planear com sabedoria para os riscos

Com todos os riscos conhecidos à partida poderemos então criar um Plano de Risco. Este documento irá identificar as acções que podem ser tomadas para reduzir a probabilidade da ocorrência dum risco. Assim, por exemplo, para o risco «podemos ficar sem os materiais necessários» então faça um acordo com um fornecedor em que se estabeleça a disponibilidade de materiais adicionais quando necessário ou encontre um fornecedor alternativo.
Contacte-nos para lhe enviarmos modelos de Plano de Risco.

Acompanhe os riscos com cuidado

Conforme o projecto vai progredindo, realize reuniões de risco quinzenais para rever os riscos que foram identificados. Responda às seguintes questões: Têm os riscos a probabilidade de ocorrerem? Existem novos riscos que temos de enfrentar? Foram completadas as acções definidas no Plano de Risco? O nosso nível de risco está a reduzir-se? Só através de uma monitorização cuidadosa dos riscos se pode controlar o nível global de risco do projecto.
E mais uma dica para o ajudar…

Mantenha a transparência

Comunique de forma aberta os seus riscos no projecto ao cliente e ao sponsor do projecto, para que todos estejam conscientes deles. Não os guarde para si. Envie aos seus stakeholders um relatório regular listando os riscos e o seu plano de acção para os solucionar.
Dar-lhes-á confiança na sua capacidade para controlar o projecto e ajudá-lo-á a ganhar o seu apoio quando dele necessitar.
Gestão de Risco em Projecto ver soluções Oracle Primavera.

Como Implementar um Processo de Gestão da Mudança?

Os projectos são normalmente realizados e envolvidos emambientes de negócio em mudança. É inevitável, então, que durante a sua vida existam e sejam requeridos alguns elementos de mudança no plano do projecto e nos seus resultados.

Assim, seja quando um cliente requer uma mudança aos seus requisitos, quando a gestão requer uma mudança na prioridade ou os membros da equipa requerem uma mudança nas suas funções, afirma-se a necessidade de um efectivo Processo de Gestão da Mudança para minimizar o impacto resultante da mudança no seu projecto. Como a implementar?

A Gestão da Mudança é o processo de monitorização e controlo das alterações dentro de um projecto. Este processo é também utilizado, em termos ITIL, para acompanhamento e controlo das mudanças na infra-estrutura tecnológica e de serviços de uma organização.

Ao gerir a implementação de alterações podemos:

Reduzir o impacto das mudanças no projecto

• Identificar as novas questões e os riscos que ocorrem por resultado das mudanças

• Garantir que as mudanças não afectam a capacidade de o projecto alcançar em tempo os objectivos desejados

• Controlar o custo da mudança dentro do projecto

A Gestão da Mudança inclui os seguintes processos:

Passo 1: Identificar a Mudança

É essencial identificar a necessidade da mudança. Qualquer membro da equipa pode sugerir uma alteração ao projecto, se acredita que esta é necessária para que o projecto possa continuar a produzir os resultados que o cliente especificou nos requisitos. Depois de ser identificada a necessidade da mudança, o membro da equipa regista a informação relevante num Formulário de Pedido de Mudança, no qual descrever a mudança e identifica os seus factores, benefícios, custos e impacto provável da mudança no projecto. O formulário é encaminhado para o Gestor do Projecto para revisão e aprovação.

Passo 2: Analisar a Mudança

O Gestor do Projecto investigará a mudança para identificar a razão para esta e o seu impacto. Então decidirá se esta é crítica para o sucesso da realização do projecto. As mudanças que não são críticas para o projecto devem ser evitadas sempre que possível para prevenir o arrastamento dos objectivos (ou seja, o aumento gradual do âmbito do projecto ao longo do seu Ciclo de Vida).

Se a mudança for considerada crítica para o sucesso, então o Gestor de Projecto quer melhorará o pedido quer procurará a sua aprovação. Em alguns casos, o Gestor do Projecto tem autoridade directa para autorizar pedidos de alteração menores; contudo, na maioria dos casos o Gestor do Projecto necessita da aprovação de um Board do Projecto (com o Sponsor e/ou mesmo o cliente).

Passo 3: Aprovar da Mudança

O Board do Projecto analisa os detalhes do formulário de Pedido de Mudança para determinar ou não se as mudanças deverão ser implementadas. Com base no nível de risco, impacto, benefícios e custo para o Projecto poderá então decidir declinar, atrasar ou aprovar a mudança pedida.

Passo 4: Implementar a Mudança

O Gestor do Projecto aprova as Mudanças que, agora serão agendadas e implementadas de acordo com a orientação definida. Depois da implementação, O gestor do Projecto deverá rever os efeitos da mudança no projecto e garantir que estas alcançaram o resultado necessário. Neste momento, poderá fechar a mudança no Registo de Mudanças do projecto.

Durante o decurso do Processo de Gestão da Mudança, o Gestor de Projecto pode monitorizar e controlar as mudanças ao projecto mantendo actualizado o Registo de Mudanças.

Lembre-se que quando a Mudança não é devidamente analisada e o benefício garantido, na maior parte dos casos, isso implica fazer de novo tudo.

O controlo da Mudança permite incrementar a probabilidade de sucesso dos seus projectos.

Documentação de Projectos

 

Para garantir o sucesso de um projecto há que o documentar rápida e eficientemente. Quais são os documentos essenciais para garantir a conclusão do projecto dentro do prazo.

Iniciação

Caso de Negócio: Para justificar o investimento financeiro no seu projecto é necessário escrever um Caso de Negócio que irá referenciar os custos e benefícios para que todos os envolvidos conheçam o retorno do investimento que irá ser obtido.

Estudo de Viabilidade: Antes do arranque do projecto, é necessário determinar se este é viável estudando o problema para avaliar a sua oportunidade de concretização, em tempo, custo e qualidade.

Charter do Projecto: temos de determinar e documentar, então, os objectivos, âmbito, equipa, moldura de tempo e resultados num Charter do projecto.

Planeamento

Plano do Projecto: Tem de criar um Plano do Projecto que relacione todas as actividades requeridas para realizar o projecto do início até ao fim. Cada actividade deve ser agendada para que possa saber o que deve ser feito e quando.

Plano de Recursos: Em seguida, é necessário planear os seus recursos documentando o custo, equipamento e materiais necessários para o projecto.

Plano de Qualidade: Tem, então de estabelecer os objectivos de qualidade para que os resultados do projecto correspondam às expectativas do cliente.

Plano de Risco: Todos os riscos devem ser documentados e identificados a sua probabilidade e impacto no projecto.

Plano de Comunicação: Precisa planear a comunicação para que envie a mensagem certa na altura certa.

Execução

Gestão do Tempo: Precisa de preparar um interface de recolha de tempo para registar o tempo que gasta no seu projecto. Com este processo pode actualizar o seu Plano do Projecto com os dados recolhidos e perceber se está de acordo com o plano.

Gestão de Custos: Acompanhe os seus custos com Formulários de Despesas. Cada despesa é formalmente registada e aprovada, para que a todo o momento possa confirmar se está a cumprir o orçamento.

Gestão da Mudança: Documente cada mudança ao âmbito do projecto utilizando formulários de Mudança. Assim poderá controlar a mudança e garantir que o projecto está no caminho certo.

Gestão de Risco: Utilize Formulários de Risco para documentar cada risco para o Projecto. Pode desta forma gerir o risco com cuidado para garantir que nada acontece que possa afectar o agendamento ou o orçamento do Projecto.

Gestão de Questões: Todas as questões que ocorrem no projecto devem ser investigadas no seu impacto no projecto e então preencher um formulário de Questões. Este registo permitirá definir e acompanhar as tarefas necessárias para resolver rapidamente a questão.

Encerramento

Relatório de Fecho do Projecto: Quando o Projecto está concluído documente todas as acções necessárias para o fechar devidamente. Isto inclui desmobilizar equipas e fornecedores, equipamento e materiais.

Revisão Pós-Projecto: Depois de o Projecto ter sido concluído pode então rever os seus sucessos ou falhas e documentá-los para o seu sponsor. Desta forma, pode mostrar que todos os objectivos foram alcançados e que o projecto foi conseguido em tempo e dentro do orçamento definido.

Aqui estão os documentos necessários. Através da sua execução devida no vosso projecto pode incrementar as suas possibilidades de sucesso. Pode ainda utilizar ferramentas que reúnem estes documentos e que possuem a capacidade de registar riscos, questões, mudanças de forma colaborativa. Veja em www. enfase.pt