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.

Garantir a realização dos benefícios

O propósito da realização de projectos é para beneficiar da mudança realizada. Os projectos são realizados para melhorar as coisas, o que faz com que seja muito importante conhecer quais os benefícios que são esperados do projecto e como estes serão medidos.

Infelizmente, muitos projectos não têm planos robustos de realização de benefícios e quando o projecto é concluído ninguém consegue dizer ou não se o projecto alcançou efectivamente o que devia realizar. Isto é muito vulgar em projectos que não são parte de um programa, porque a gestão de programas está muito focada na realização de benefícios. Ao contrário do que acontece com as metodologias de gestão de projectos.

Clarifique o que é um benefício

Todos sabemos oque é um benefício, não é? Na realidade, toda a gente na gestão do projecto tem uma ideia diferente acerca dos benefícios que o projecto irá realizar. As agendas de cada um funcionam aqui, como é esperado. Os stakeholders individuais do projecto irão procurar «o que é que está aqui para mim» e irão potencialmente perder de vista os benefícios essenciais que irão ser realizados de forma geral por toda a organização.

Devemos conseguir alinhar com clareza quaisquer benefícios do projecto relativamente a metas mensuráveis que contribuam para os objectivos.

Podemos ainda incluir benefícios que tenham um impacto único numa área ou departamento ou que estejam nas agendas pessoais, mas estes devem ser suplementares à compreensão comum dos benefícios gerais do projecto.

 

Nomeie os responsáveis pelos benefícios

Os benefícios como as actividades precisam de responsáveis. Se não se nomeia o responsável pelo benefício, este não será medido e pode nunca ser realizado. Normalmente, o responsável pelo benefício é a pessoa que vai receber o benefício.

Faça a designação dos responsáveis o mais cedo possível – logo que o business case do projecto tiver sido aprovado. Estas pessoas podem colocar a realização e a medida dos benefícios nos sues objectivos anuais e nos das suas equipas.

Não chega nomear de forma simples os responsáveis. Estes têm de assumir a responsabilidade total pelo benefício, o que significa que eles têm de compreender como será realizado e como será medido.

 

Defina um processo de registo de benefícios

Não chega nomear os responsáveis. Eles devem assumir a responsabilidade total pelo benefício, o que significa que eles têm de compreender como será realizado e como será medido.

 

Defina um mecanismo de registo dos benefícios

Pode considerar que o proprietário dos benefícios quer ser responsável pela criação de um mecanismo de registo do benefício. Ao contrário eles quererão ajuda de quem coordena o projecto e do PMO. Algumas ferramentas empresariais de gestão de projecto, como o Oracle Primavera P6, têm a capacidade de registar a informação que será útil para acompanhar a realização dos benefícios e assim deve fazer uso desta ferramenta para capturar os dados importante e gerar os relatórios.

O PMO é normalmente a estrutura que standardiza a forma como os benefícios são acompanhados e medidos, mas como os benefícios são de tantos tipos e variedade, uma abordagem standard pode não ser prática em todas as circunstâncias. Chegados aqui a conclusão mais importante é que tem de haver obrigatoriamente um registo formal, um acompanhamento e uma medida dos benefícios.

Temos, ainda, de estar conscientes que no início o projecto pode realizar rápidos sucessos e podem ver-se benefícios significativos a serem realizados. Mas depois deste primeiro impulso os resultados podem cair. Os proprietários dos benefícios devem estar preparados para que isto aconteça. Estabeleça um período de tempo para o registo de benefícios, após o projecto. Pode concluir que, depois de um ano, todos os benefícios foram absorvidos pelo negócio e não é necessário continuar a acompanhar e registar os mesmos.

O mecanismo de registo dos benefícios deve também incluir uma forma para que o proprietário dos benefícios possa partilhar com as pessoas do departamento, porque muitas vezes os objectivos das pessoas podem estar ligados aos benefícios esperados do projecto.
 

Em suma,

O acompanhamento dos benefícios é muitas vezes muito difícil, porque muitos dos business cases definem somente benefícios intangíveis. Se houver o cuidado de envolver as pessoas desde a preparação do business case, teremos benefícios estruturados, um plano para os realizar e um método para os medir. Então tudo o que os proprietários dos benefícios necessitam fazer é estabelecer a melhor forma de usar os resultados do projecto para obter o máximo dos benefícios e registá-los.

Fácil! Não é?

LQ

Melhor Gestão de Projecto na recuperação económica

Não há nada de bonito nesta recessão económica. A economia está a mudar, muitas companhias estabelecidas no mercado estão a desaparecer ou sofrem processos de compra e de fusão, as indústrias estão a operar em modo de sobrevivência preocupadas por evitar riscos que as possam colocar em vulnerabilidade. Para sobreviver, as grandes empresas têm de se manter na vanguarda da inovação e das tendências de mercado.

Mas nem tudo tem sido negativo!

Aparentemente com a queda de empresas lentas e ineficientes afectadas pela recessão, foram criadas oportunidades para outros negócios florescerem. Para as companhias que conseguiram ultrapassar estas grandes dificuldades e estão a navegar no actual horizonte de negócios, jogar pelo seguro não é a forma de ter sucesso, mas também não o é avançar sem cuidados.

Um factor chave que faz a diferença nas empresas é a execução inteligente dos projectos. Actuar sobre os projectos que são mais lucrativos e agindo com margens de erro muito pequenas, permitirá que os negócios sejam capazes de maximizar o valor das suas actividades e assegurar que irão operar com lucro nos anos seguintes.
 

Manter o projecto dentro do prazo

Quando se trata do sucesso dos projectos este é o aspecto mais importante. É essencial aplicar métricas às realizações, mas quando queremos recolher a informação adequada para esse efeito podemos levar imenso tempo. Se estabelecermos inícios e fins claros para as actividades poderemos aplicar métricas valiosas de tempo que façam sentido para os stakeholders do projecto e, sobretudo, para o cliente, que verá o resultado comparado com a métrica de baseline.

O estabelecimento de uma baseline é obrigatório na realização de um projecto com métodos sérios e métricas com valor.
 

Do custo do projecto

A maioria das empresas não conhece o verdadeiro custo por projecto e isso pode conduzir a um mundo de trabalhos. Se sabe quais são os projectos que estão ser lucrativos poderá alocar os recursos a projectos com um perfil similar e estar mais confiante na sua performance e no sucesso. Mantenha curtos os elos de comunicação nestes projectos e monitorize constantemente a medida em que eles estão alinhados com o custo e o orçamento.

Estes dados ajudarão a determinar quais os clientes que permitem manter as margens e aqueles que pela sua actuação impedem ou dificultam o progresso e reduzem ou destroem as margens.
 

Utilize eficientemente as ferramentas

Qualquer ferramenta é tão efectiva como a pessoa que a está a usar. Mesmo o melhor software irá falhar se não tivermos um plano para o utilizar. Isto não significa que o software possa ser optimizado. Quando temos de gerir projectos múltiplos e os dados complexos que estão associados com a sua realização, uma ferramenta que agregue e prepare os dados automaticamente pode poupar muito tempo e confusão enquanto fornece uma visão clara e transparente sobre o estado dos projectos.
 

Desenvolva sem receio os projectos

Executar consistentemente os projectos e realizar valor é muito importante. Para isso tem de assumir projectos inovadores que requerem algum risco. O segredo está em saber quando e como assumir esses riscos. Pode ajudar muito poder avaliar os recursos disponíveis e determinar, a partir dos dados da experiência, quais os tipos de projectos mais lucrativos. Armados com essa informação, mesmo quando um projecto atrasa, não deve ser muito difícil recuperar. Mas mais do que isto, por tentarmos novos projectos continuamos a melhorar e a refinar as métricas de sucesso.

Agora chegámos ao tempo de começar a quebrar a estagnação associada à recessão. Os novos projectos levam a novos clientes, o que conduz à melhoria das margens e dos lucros e a vantagens competitivas. Estará aí um mundo de oportunidades se alterarmos as nossas perspectivas, nos equiparmos com metodologias e ferramentas. Mas muitas companhias persistem escondidas nos seus abrigos de crise.

Temos de tomar a iniciativa para nos colocarmos na cabeça da corrida.

LQ

O que é gestão de projecto?

Há dois tipos de projectos – os cínicos e os genuínos!

Os cínicos são aqueles que não são mais do que formas de atribuir pessoal a mais – colocando-os em posição de que não podem faze mais «mal» - o que no fundo é o resultado directo da f alta de medida de performance, são projectos que apesar de pretenderem uma mudança são baseados em mentira e assumpções «económicas» pretensamente estudadas. Ao mesmo tempo. São também cínicos os projectos que são criados para glorificar o seu criador com mostras de grande dinamismo aparente. Deste tipo de projectos devemos fugir!

Para além do cinismo, a gestão de projecto é utilizada para gerir uma mudança específica que está posicionada fora das actividades do dia-a-dia e dos horários fixos. Esta é a abordagem que a maioria das metodologias toma para a definir. Terá habitualmente um orçamento específico e um objectivo para alcançar.
 

O que não é?

Apesar de todas as ferramentas e técnicas sofisticadas disponíveis não se trata de nenhuma mágica. É senso comum e utiliza todas as boas técnicas de gestão só que aplicadas a um trabalho muito específico. Entretanto, algumas ferramentas potencialmente úteis deram origem a uma indústria.

PRINCE2, por exemplo, é um método poderoso de gestão de projecto – não é uma garantia de sucesso e deve ser usada apropriadamente para a dimensão e complexidade da mudança que está a ser gerida. Um detalhado Documento de Implementação do Projecto (PID) não garante o sucesso se levar mais tempo a ser feito do que a mudança por si. Projectos há que a documentação é usada para dar a ilusão do progresso quando no terreno a actividade é praticamente inexistente.

Um plano de projecto detalhado e compreensivo pode ser um fim em si próprio e criar a ilusão de movimento às custas do real progresso. Criar e editar o plano não é o mesmo que gerir o projecto, mas pode oferecer horas de distracção ao gestor de projecto ingénuo que usa isto como que de um substituto ao trabalho no projecto.

Alguns dos pacotes de software de gestão de projecto oferecem um alto nível de sofisticação que para um projecto orientado à realidade podem distrair dos resultados chave ou levar-nos até um nível de detalhe desnecessário.

O Office de projecto (ou de programa, ou mesmo os dois) pode criar um sentido controlado de mudança que dê suporte aos gestores. Mas em muitos projectos já vi os seus stakeholders perderem mais tempo preenchendo cores em relatórios do que a tratarem dos seus pontos de acção definidos em reunião. Quando se perde tempo desta forma a anarquia instala-se já que se pretende confiar nestes relatórios muito com plicados. O gestor de projecto gasta mais tempo atrás dos suspeitos habituais dom que a avaliar e comunicar o verdadeiro impacto nas milestones.

 

O que deve ser?

A gestão de projecto deve ser apropriada e proactiva à escala da mudança. Os desenvolvimentos recentes e as técnicas ‘agile’ são um reflexo desta tendência. Nem todos os projectos necessitam ser definidos e alocados até um nível elevado e também nem sempre se necessita de um gestor de projecto específico. Muitas vezes o dono do projecto é o gestor de linha e o trabalho espalha-se através de diversas equipas e pessoas podem assumir a responsabilidade por diferentes partes do trabalho em diferentes etapas. Nem sempre se necessita de software especializado. Uma folha de cálculo pode ser suficiente ou pode ainda usar um gráfico desenhado à mão.

Contudo, muita da melhor gestão de projecto está nos comportamentos e na liderança. Gerir stakeholders, as suas esperanças, medos e políticas é vital para o sucesso. Motivar a equipa do projecto e investir tempo na equipa especialmente no lançamento do projecto irá permitir obter óptimos dividendos. Possuir um ambiente em que seja fácil o controlo e actualização do progresso, onde a comunicação é constante e mais importante ainda, onde é seguro ter uma perspectiva aberta relativamente a questões do projecto, permite remover a maioria dos obstáculos.

Tal como muitas outras coisas no trabalho, tudo se resume a inter-relações. E isto é verdade quer lhe chamemos Gestão de Projecto, Gestão de Programas ou Gestão da Mudança. O que necessitamos por cima disto é fornecer a estrutura e os recursos que dependerão da escala e natureza da transformação que pretendemos realizar.

Como decidir com PRINCE2

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

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

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

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

Luis Quintino

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

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

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

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

Estratégia de Gestão de Projecto

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

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

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

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

Exiegências do Mercado actual

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

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

Planear projectos no ambiente de Help Desk de TI

Tradução de post de Anna Halstead, PMP

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

Estamos a falar de que tipo de projectos?

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

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

Duas razões do fracasso dos projectos

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

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

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

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

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

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

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

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

Análise de Risco do Projecto: O que é e porquê fazer?

Os planos de projecto são, evidentemente, acerca do futuro tudo o que trata do future tem certa incerteza associada. Quando se estima a duração da actividade em 5 dias está intrinsecamente assente que isto pode provavelmente não ser assim mesmo. Pode haver uma pequena quantidade de incerteza ou uma grande, mas alguma haverá com certeza.

Como resultado da incerteza acerca das durações das actividades, qualquer estimativa da data de conclusão do projecto é só isso, uma estimativa. Esta será válida tão só as estimativas das durações das actividades se verifiquem como verdadeiras. Como há sempre muitas actividades, é quase certo que muitas delas tomem menos tempo que o estimado enquanto outras levarão mais tempo que o estimado.

Assim, na realidade o fim do projecto é provável que não possa ser projectado de forma tão determinística como o CPM e o PERT, mas esteja, talvez, dentro de um limite de datas que se pode espalhar simetricamente à volta da estimativa. (Na realidade é pior do que isso. O uso de estimativas determinísticas também introduz um preconceito de tal forma que as estimativas tendem sistematicamente para serem optimistas.)

A Análise de Risco do Plano (Schedule Risk Analysis) é uma técnica que reconhece esta incerteza ao substituir a duração determinística para cada actividade pela distribuição representando os limites das durações prováveis. Existem métodos analíticos para processar as distribuições de probabilidade em casos simples, mas as redes de projecto são normalmente muito complicadas para que estes possam ser aplicados.

A solução é utilizar uma simulação Monte Carlo. Isto é como simular um evento da vida real através do lançamento de dados, só que isto é feito num computador. Os computadores podem gerar aquilo que é denominado como números pseudo-random. Não são verdadeiramente ao acaso, porque eles podem ser reproduzidos se alguém conhecer o mecanismo de geração: utilizando estes números pseudo-random, podemos gerar séries de distribuições desejadas e estas são usadas numa simulação Monte Carlo para simularem sistemas físicos sobre um grande número de cenários gerados ao acaso.

A simulação Monte carlo tem aplicações em muitas áreas. No contexto de uma rede de projecto, a simulação Monte Carlo:

Usa uma amostra da distribuição definida pelo utilizador para cada duração da actividade.

Faz uma análise de caminho crítico (CPM) com base nas durações da amostra.

Armazena os resultados desta análise de tempo (geralmente de uma forma sumária como um histograma).

Repete os passo de 1 a 3 várias centenas ou milhares de vezes.

No fim deste processo pode produzir histogramas representado a probabilidade das distribuições de qualquer resultado de interesse, que geralmente incluem datas mais cedo e mais tarde de início e datas de fim, folga livre e total e custo para cada actividade.

Como resultado, a data de fim estimado do projecto e outras milestones importantes são representadas por distribuições de probabilidade em vez de estimativas com um único ponto. Assim em vez de prever que o projecto será completado em determinada data – uma previsão que o mais certo é ser errada – podemos fazer previsões mais realistas tais como «há 90% de hipótese que o projecto termine até 31 de Maio.»

Mas, talvez a razão mais importante para fazer uma análise de risco é o equilíbrio anteriormente mencionado, que significa que uma estimativa de um só ponto da conclusão do projecto realizada através de um determinístico CPM ou PERT não está muitas vezes nem dentro dos limites representados pela distribuição probabilística produzida pela análise de risco. A razão para isto é um fenómeno denominado merge bias.

UM equilíbrio fundido (merge bias) ocorre sempre que dois ou mais caminhos convergem numa rede e a incerteza acerca das suas durações é tal que qualquer dele pode tornar-se crítico. Para ilustrar este equilíbrio fundido, considere uma actividade que só tem dois predecessores que correm em paralelo. Suponha que cada uma possa levar qualquer coisa como de 1 a 6 dias com probabilidade igual. E suponha, ainda, que elas não ocupam fracções de um dia. (Isto pode parecer um pouco artificial e até é. No entanto, isto permite que o ponto a ser feito por analogia com o lançamento de dados e sem nos envolver numa montanha de cálculo.)

A duração esperada para cada actividade individual é, claro, de 3,5 (já que 1+2+3+4+5+6 todos divididos por 6): mas qual é o tempo esperado para ambos para se concluírem? A tabela seguinte mostra todos os 36 resultados possíveis para o par de actividades, que pode ser simulado pelo lançamento de dois dados. (Assim , por exemplo, se a primeira levar 5 dias e a segunda só 3 dias. O tempo tomado por ambas para serem completadas é 5 dias e pode ser visto na tabela.

	1	2	3	4	5	6
1	1	2	3	4	5	6
2	2	2	3	4	5	6
3	3	3	3	4	5	6
4	4	4	4	4	5	6
5	5	5	5	5	5	6
6	6	6	6	6	6	6

Das 36 possibilidades, só uma tem 1 como máximo enquanto 11 têm 6 como máximo. Assim tendo só dois caminhos paralelos podemos ver que o tempo que leva a realizar ambas as actividades é provável que seja maior do que a estimativa determinística de 3,5 dias. Se fizermos as contas vemos que o valor esperado é na realidade quase 4,5 dias. Com 3 actividades paralelas, o valor esperado é quase de 5 dias e com 5 actividades é cerca de 5,4 dias. E com 10 é de 5,8 dias. A convergiram claramente para 6 conforme o nº de caminhos paralelos aumenta).

Outra forma de olhar para isto é declarar a Lei de Murphy de uma forma menos pessimista do que Murphy.

“Se houver muitas coisas que possam correr mal então pelo menos uma irá correr mal.”
Numa rede de projecto com caminhos paralelos, basta um caminho correr mal para atrasar a conclusão do projecto. (correr mal significa tão só durar mais do que o esperado. Isto não implica que foi feito algum erro, mas pode ser só o resultado da inevitável incerteza envolvida na estimativa original). É isto o merge bias.

“Nestes assuntos a única certeza é que nada é certo.”  (Plínio o Velho)

A Consultoria de Gestão e o Fracasso dos PMO

Os PMO que foram implementados em grandes companhias fracassam porque perdem, na sua maioria, o seu tempo em intermináveis batalhas com outros departamentos ou em crises de identidade que impedem a afirmação da sua missão.

O problema é que o culpado habitual por esta ineficácia e falhanço do PMO, ou seja, a falta de compromisso da gestão, não é de facto a causa primária. Na realidade, o denominador comum do fracasso dos PMO pode ser atribuído antes ao papel desempenhado pelos consultores de gestão que estabeleceram o PMO. Estes consultores desempenharam um papel instrumental nas três áreas abaixo durante a criação do PMO, criando defeitos estruturais de grande dimensão, que embora com todas as tentativas de resolução se mantêm como uma nódoa que não se apaga.
 

Semear as sementes da confusão nos executivos

Mantém-se uma confusão perpétua mas cabeças dos executivos acerca das funções, responsabilidades e competências dos PMO. Isto nasce porque os consultores contratados para o estabelecer focam-se, de forma exclusiva, em estabelecer um PMO que exiba características de uma função de reporting e pouco mais. Neste arranjo, os status de diferentes projectos e programas são agregados, racionalizados e então apresentados à equipa de gestão para a tomada de decisões.

O que acontece é que muitos dos executivos são incapazes de vestir a roupa do sponsor do projecto (antes desempenhado pelo CEO) e tomarem as decisões importantes para os projectos que estão debaixo do seu âmbito de decisão. Ainda mais, muito poucos executivos possuem ideias sólidas acerca de como um PMO centralizado deve funcionar. Assim, é lógico encontrar a falta de compromisso executivo quando o PMO entra em modo de cruzeiro.
 

Nunca foi uma questão de metodologia de projecto

Na fase de lançamento, a companhia de consultoria que estabelece o PMO presta muito pouca atenção à metodologia de programa / projecto ou à standardização dos documentos de projecto e dos modelos bem, ainda, à formação das pessoas do PMO na realização das suas funções para além do reporting. O próprio reporting sofre da ausência de uma abordagem estruturada e muitas vezes existe uma exagerada dependência das «apresentações de Powerpoint».

Depois após a implementação, o PMO armado unicamente com slides coloridos está muito mal equipado para apoiar ou realizar projectos e programas. Segue-se um crescente fracasso dos projectos e todas as tentativas para rectificar esta situação fracassam irremediavelmente.

Tudo isto porque as soluções utilizadas para enfrentar a fraqueza estrutural derivam da experiência de lançamento do PMO. Como exemplo, muitos executivos assumem que, só porque o PMO realizou resultados durante a fase de lançamento, irá depois, com uma abordagem similar e sem trabalho adicional, fornecer os mesmos resultados positivos.
 

Demasiada confiança em funções e responsabilidades centralizadas

Outra descoberta desconcertante é que as funções e responsabilidades, estruturas de processos e governação executadas pelo PMO estão baseadas na sua vida no lançamento. Encontramos muitas vezes funções de 'Launch PMO', 'Launch Manager', 'Launch Director', 'Launch Gate', 'Launch Project Life Cycle', 'Launch Check Lists', etc. como parte do léxico. Em muitas vezes, só o prefixo ‘Launch’ é removido das descrições de funções e processos, mas a essência está inalterável. Subsequentemente, o PMO e a sua equipa são incapazes de se adaptarem ao ritmo da vida da companhia e descobrem-se na periferia da realização dos projectos.

Para remediar a situação, são aplicadas duas soluções típicas. Em primeiro lugar, são recrutados «gestores de projecto certificados» e espera-se que estes realizem os projectos dentro do plano. Contudo, na ausência de uma metodologia sólida de gestão de projecto, vemos que muitos ficam parados num limbo.

Em segundo lugar, são recrutados para a remediação consultores muito dispendiosos com experiência extensiva em trabalho com PMOs. Em alguns casos, os consultores são na realidade contratados da mesma companhia de consultoria que estabeleceu o lançamento do PMO e falham miseravelmente quando lhes é atribuída a responsabilidade de resolver os problemas e sanar o PMO. Tudo isto exacerba o problema e marginaliza o papel do PMO na vida da companhia.

Para ser justo com os gestores de gestão, estes são normalmente contratados em virtude da sua competência no domínio e não pelas suas competências em PMO. Este é um valor adicional que é introduzido como uma parte dos serviços de consultoria sem custo adicional. Esta prática está generalizada de tal forma que os executivos ficam a pensar porque é que há tanto fracasso de projectos apesar do lançamento com sucesso de novas linhas de negócio.

Para evitarem cometer o mesmo erro segunda vez, os executivos devem por bem escrutinar as capacidades de PMO dos seus consultores, para além do conhecimento do domínio. Em alternativa, podem contratar um especialista de PMO para a companhia, que trabalhe em colaboração com os consultores na fase de lançamento e assegure que é entregue um PMO adequado, equipado com a metodologia certa e os recursos estabelecidos.

Os executivos devem procurar optar por companhias que forneçam a capacidade de PMO, mas também transfiram as competências para os futuros responsáveis pelos mesmos na companhia.

Selecção de Software de Gestão de Projecto

O software de gestão de projecto é desenvolvido por dezenas de fabricantes co9m as mais variadas funcionalidades e sofisticação e correspondentes variações de preços. O problema que se pôe às empresas é como encontrar a ferramenta adequada. Esta não é uma tarefa fácil porque não dispomos da possibilidade filtrar todo o «barulho» de marketing, que permita seleccionar a ferramenta certa para a situação ou para a nossa carreira.

Tipos de projectos que fazemos	Categoria de Software
Programas com sub-projectos múltiplos com uma grande equipa e dependências complexas entre as actividades	4
Projecto estratégico: afecta múltiplos depart6amentos ou organizações com um grande orçamento e uma grande equipa, fornecedores externos com muitos stakeholders	3 ou 4
Projecto cliente – fornecedor: equipa de 3 a 8 pessoas com um importante orçamento e um prazo fixo e complexidade na sequenciação de membros da equipa, fornecedores e materiais	2 ou 3
Pequeno projecto: realizado para outro departamento ou para um cliente externo. Equipa de 3 a 5 pessoas, sem orçamento e com uma data de entrega importante	1 ou 2
Projectos ad-hoc: realizados dentro do departamento com uma equipa de 2 ou 3 pessoas incluindo o gestor do projecto e demora menos de um mês sem orçamento e uma data de entrega flexível	1

Os profissionais usam software da categoria 3.

As Categorias de Software

O software disponível encaixa nestas categorias com grandes diferenças de preço conforme vamos subindo a escada.

1. Software web ou baseado na cloud que conserva a informação de projecto com planeamento limitado e permitindo a distribuição de informação, acompanhamento de problemas e colaboração entre os membros da equipa. Se não necessitar de acompanhar de perto o progresso ou fazer relatórios de status, este tipo de software é suficiente. Alguns exemplos Apolo e Dotproject.
2. Software de cloud ou instalado que oferece planeamento com datas de início e fim para cada actividade. Quando a situação muda, terá de introduzir novo início e fim. Se não está a gastar muito dinheiro no projecto e se este é de importância menor este software permite-lhe acompanhar o projecto, saber onde está e reportar o progresso. Exemplos são o iManageProject e Quickbase.
3. Software instalado ou de cloud que possui algoritmos para optimizar um plano e a construção de um orçamento para o projecto. Pode introduzir as actividades, o trabalho / duração das mesmas, precedências e disponibilidade de recursos. O software calcula o plano e o orçamento e fornece ferramentas avançadas para detecção de problemas e modelação de situações. O software de categoria 3 é aquele que é usado pelas pessoas que habitualmente gerem projectos. Exemplos deste são Microsoft Project e Oracle.
4. O software de servidor para gerir centenas de projectos, equipas com muitas pessoas e portfólios de projectos. O software empresarial de gestão de projectos custa muitos milhares de euros. Exemplos são Microsoft Project e Oracle, cada um com a sua versão de portfólio.

As duas primeiras categorias são adequadas para projectos mais pequenos. As capacidades são limitadas assim como a curva de aprendizagem. A sua ineficiência e falta de capacidade é um pequeno incómodo porque o projecto só tem umas poucas pessoas e uma duração curta. O custo deste software é baixo , mas estas não são ferramentas dirigidas a profissionais que regularmente gerem projectos.

O passo grande é o salto da categoria 2 para a 3. Neste ponto, o software muda de plano estático, em que as datas e durações são introduzidas manualmente, para dinâmico dirigido pelos recursos e as dependências. O plano actualiza-se automaticamente sempre que se adiciona ou remove recursos ou a sequência das actividades. Estas funcionalidades poupam muito tempo aos gestores de projecto na criação, optimização e actualização. A curva de aprendizagem é muito mais ingreme e o investimento só vale a pena se o projecto for crítico para a organização e a gestão pretender ter a possibilidade de identificação e correcção precoce. Estas soluções tornam-se indispensáveis quando se trata de projectos de complexidade ou de grande dimensão ou programas com múltiplos sub-projectos

Luís Quintino.

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

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

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

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

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

Avaliar o níveis de variância

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

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

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

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

Melhorar a Performance

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

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

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

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

Manter-se no caminho com exactidão

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

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

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

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

Categorias de Riscos a ter em atenção

Os riscos são inevitáveis nos projectos. Não podemos evitar os riscos e conseguir uma suave execução do projecto. Temos somente de aceitar este facto e afastarmo-nos dos riscos iminentes. Estes eventos de risco estão muito bem escondidos em lugares dos mais improváveis, mas confiamos sempre em que o bom tempo e a bonomia dos nossos concidadãos nos permitam alcançar algum sucesso sem sermos confrontados com um destes eventos prováveis.

Os gestores de projecto pesquisam os riscos em locais conhecidos ou dependem por completo da experiência quando identificam riscos potenciais no seu projecto. O seu registo de riscos vai melhorando conforme eles adquirem experiência. Mas este tipo de educação é muito dispendiosa para o projecto e para o sponsor do projecto. Uma exploração sistemática de riscos em áreas problemáticas conhecidas deve ser uma obrigação em todos os projectos. Esta exploração deve ser sistemática e deve, para facilitar, ser realizada com a utilização de uma lista de verificação. Não se pode deixar um aspecto tão crítico do projecto para a memória do gestor de projecto. Esta lista deve ser um documento vivo e deve ser actualizada sempre que factos novos ou conhecimentos estejam disponíveis durante a execução dos múltiplos projectos.

Em sumário, o gestor de projecto deve ter atenção às seguintes áreas de risco:

• Âmbito
• Plano e Esforço
• Asumpções, Dependências e constrangimentos
• Tecnologia
• Critérios de Aceitação e Qualidade
• Pessoas, experiências e competências
• Regulação e Política

Todas estas áreas correspondem a uma lista de perguntas que os gestores de projecto devem colocar quando, de forma obrigatória e regular, abordarem a revisão de riscos para o projecto.

O jogo do projecto – uma fábula

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

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

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

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

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

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

O Jogo do Projecto

Iniciei o trabalho com uma equipa de projecto de uma grande companhia que está a preparar a realização de uma obra de grande dimensão – que é mesmo o propósito da mesma companhia e veio-me à cabeça um turbilhão de ideias com os problemas enfrentados no início de um projecto e com as concepções diversas que se tem sobre a gestão de projecto.

O desenvolvimento dos grandes projectos de engenharia como a ilha Jumeirah no Dubai ou o desenvolvimento do Airbus A380, são concluídos com atraso de perto de dois anos relativamente ao plano. Estes são só dois exemplos, mas essa é uma constante porque esta performance dos projectos não é uma excepção. Desde a remodelação da cozinha até ao desenvolvimento de um produto, os projectos tendem para estar atrasados no tempo relativamente ao plano ou acima do orçamento, ou ambos.

É tecnicamente possível fazer melhor mesmo em projecto de grande escala, com envolvimento de nova tecnologia como o exemplo do programa Apollo, que alcançou o seu propósito 5 meses antes do prazo, ou, para falarmos de um exemplo mais perto, a Ponte Vasco da Gama (2 meses antes do prazo). Mas estes não são fenómenos que se repitam com facilidade.

Assim, é legítimo perguntar se não somos capazes de fazer melhor, considerando as ferramentas que agora possuímos. A chave é, parece-me, que a gestão de programas e de projectos são tratadas como campos técnicos quando deviam ser olhadas como jogos, visto que os resultados são consequência de decisões tomadas por diversos agentes independentes.

Na gestão de projecto decompõe-se um projecto em actividades mais pequenas, às quais se atribuem durações, recursos e constrangimentos de tempo e de precedência. De seguida são realizados cálculos que produzem gráficos de Gantt, são identificados os perfis para os recursos, o caminho crítico, etc. A ferramenta mais comum é aquela que permite realizar o Método do Caminho Crítico (todas as ferramentas no mercado). Recentemente, chegou Eli Goldrath com a sua Cadeia Crítica da Gestão de Projecto (Critical Chain) que se foca nos recursos ou a Matriz de Desenho da Estrutura (Design Strucuture Matrix) que visa gerir as interacções entre as actividades.

Estes são todos modelos consistente e muito bons para as apresentações de soluções, mas estão muito longe do dia-a-dia da gestão de projecto dirigindo-se muito mais ao primitivo processo de listas de itens de acção. O problema mais óbvio com o uso destas ferramentas é que a duração para as actividades elementares é desconhecida e nunca vi uma organização que realizasse um esforço sério para recolher estes dados.

Uma actividade de projecto não é como uma actividade de montagem fabril que possa ser cronometrada ou registada em vídeo. O trabalho de projecto nunca é completamente repetitivo, se repetimos sempre a mesma acção, então é chamado produção ou transacção, mas não um projecto. Como nunca fizemos esta actividade de projecto antes, não pode dizer quanto tempo levará, mas pode obter outra informação dos seus componentes e pode estimar as similaridades ou as diferenças, com as actividades que já realizou antes, se mantém um registo disso. O trabalho de engenharia é organizado por projecto e o tempo dos engenheiros é controlado por timesheets, mas estas folhas são preenchidas após os factos pelos próprios engenheiros sem rigor efectivos e não são exactas.

Há formas de estimar melhor o trabalho das actividades, mas esse não é a preocupação principal dos gestores de projecto, ao contrário, o seu pensamento está focado em frases que começam com «Nada mais interessa, se…». Inicialmente, um gestor encarregado de liderar o projecto criou um plano que deve ser aprovado e nada mais interessa. O propósito do plano não é assim estimação mas sim persuasão. Como é que isto será realizado? Não há uma forma directa de o dizer, porque obviamente depende de quem deve ser persuadido. O que é constante é que o gestor de projecto está a vender, e irá fazer tudo o que for necessário para fechar o negócio.

O Desafio dos Projectos Internacionais

O mundo de trabalho contraiu-se significativamente nos últimos 20 anos e agora é muito comum trabalhar com parceiros internacionais em projectos. Isto pode ser um projecto de transformação, ou parte de um acordo de outsourcing, ou num modelo de offshoring, que é mais comum nas organizações que exigem processamento de transações em «follow the sun». Claro, que a companhia pode também ter divisões espalhadas por todo o mundo já que os projectos internacionais nem sempre envolvem terceiras partes, antes correspondem a projectos contratados.
Para gestores de projecto isto significa que estarão envolvidos com diferentes tipos de stakeholders em projectos. Gerir projectos internacionais pode ser muito interessante e recompensador, mas estes projectos são também um grande desafio. Há algumas questões importantes a ter em conta em projectos internacionais.

A Língua

Pode parecer óbvio mas se está a trabalhar fora do paìs é muito pouco provável que toda a sua equipa de projecto fale a mesma língua. Estamos habituados a trabalhar em Angola, Moçambique, Brasil e mesmo aì há diferenças que devem ser explicadas. O problema com uma língua comum é muito maior se estiver a trabalhar com colegas que não trabalham regularmente na sua língua.
No início de um projecto vale a pena especificar qual vai ser a principal língua de trabalho do projecto. Em projectos fiderados a partir de um país de língua inglesa ou de uma companhia também de língua inglesa, isto naõ significa ser a língua inglesa para tudo. A ferramenta de gestão de projecto até pode ter interfaces em várias línguas. A equipa no local pode introduzir os dados de produção com menus na sua língua mas mantendo a língua oficial do projecto.
Respeite os membros da equipa que não estão a trabalhar na sua língua nativa. Minimize o calão ou os termos técnicos adaptados e faça com que a sua escrita seja falada e escrita de forma clara.

O Tempo

As diferentes culturas têm diferentes interpretações sobre o tempo e, para algumas, as milestones são só um guia. Podemos valorizar a pontualidade, mas outros membros da equipa podem não ter a mesma opinião sobre a hora de começar uma reunião. A única forma de gerir isto é ter uma conversa franca com todas as pessoas envolvidas, explicando os desafios potenciais e pedindo a colaboração para os enfrentar. É melhor ter sempre esta conversa o mais cedo possível do que perder muito tempo em esperas para reuniões ou chamadas telefónicas.

Funções e Responsabilidades

A função do gestor de projecto pode ser muito respeitada no seu paìs, mas o seu trabalho pode não ser compreendido noutros lugares. Os seus colegas noutros paìses onde a companhia tem estruturas podem não receber direcções porque podem não o ver (ou à sua função) como muito importante. Igualmente, podem não ter recebido suficiente orientação acerca de como as suas responsabilidades de projecto se enquadram com a sua função e a deles relativamente à sua.
Este desafio vai ser descoberto tarde, infelizmente, e já bem depois de ter começado a trabalhar no projecto e, assim, o seu plano de acção para isto será enfrentar um problema que já ocorreu. Fale com as pessoas e colegas que já tiveram a mesma experiência em trabalhos internacionais. Pode ainda envolver os gestores locais que podem ajudar a definir com as suas equipas as expectativas acerca do projecto, as funções deles e o papel do gestor de projecto relativamente a elas.

Ferramentas

Faça o máximo com o software disponível para si. Use o melhor software de gestão que puder usar e que possa suscitar a colaboração e compreensão da equipa relativamente ao projecto.
Algumas ferramentas têm capcidades de menssagem instantãnea, como por exemplo o Skype. Este tipo de tecnologia significa que pode estar ligado aos membros da sua equipa mesmo quando eles não estão a trabalhar na mesma sala. Mas elas servem melhor quando a diferença horária não é maior que um par de horas.
As ferramentas como blogues e wikis que permitem trabalho assíncromo são valiosas nas situações em que as diferenças horárias são muito grandes. Pode ainda registar apresentações ou ‘conference calls’ e torná-las disponíveis mais tarde. Pense criativamente sobre os problemas que tem e que precisa de resolver e utilize de forma adequada a tecnologia.

Equipas virtuais

A gestão de equipas virtuais é difícil e exige muito compromisso de todos os envolvidos. Tem de ser muito melhor na documentação, na partilha de conhecimento e na construção da equipa, do que quando tem tudo e todos estão na mesma sala. Estar atento aos desafios das equipas virtuais é o primeiro passo para identificar os métodos que o irão a manter a si e à equipa no caminho certo.
Temos todos de aprender muito com culturas diferentes e trabalhar em equipas internacionais pode ser uma das mais recompensadoras experiência da gestão de projecto. Quando olhamos os benefícios de trabalhar em projectos internacionais, estes desafios de que falámos são só uma parte da rica experiência que resulta de um ambiente de trabalho que se amplia e é global.
Luís Quintino

Indicadores Chave de Perfomance de Projecto

Alguns KPI que podem ser usados para provar o valor do PMO e demonstrar a sua efectividade.

Tempo para o Mercado

• Tempo para o Mercado = tempo passado desde a concepção da Ideia até à Realização
• Tempo para o Mercado Alternativo = Tempo de Realização Real – Tempo Planeado para a Realização

O PMO pode melhorar o tempo para o mercado do produto de duas formas. Primeiro, pode aumentar a velocidade à qual cada um dos projectos é concluído. Os benefícios disto são óbvios, já que um projecto que é concluído mais rapidamente geralmente significa maior satisfação do cliente e da companhia porque estará disponível mais cedo. O PMO também melhora o tempo para o mercado ao promover uma melhor aderência aos planos do projecto. Ao fazer isto promove a satisfação do cliente, melhora a confiança na equipa do projecto e oferece uma melhor capacidade de previsão do futuro dos ciclos de vida futuros do projecto.

Mas ainda mais importante, isto irá garantir que um produto dependente de tempo não irá falhar o seu prazo, por razões inerentes ao projecto, para não reduzir ou fracassar no seu sucesso. Os PMO que de forma consistente melhoram o tempo para o mercado podem melhorar os seus processos e ser desenvolvidos bem e mais rapidamente.

Disponibilidade de Serviço

• Disponibilidade de serviço = Data Real de Início – Data Óptima de Início

A disponibilidade de serviço refere-se ao tempo que leva a iniciar um projecto em comparação com a data desejada de início. Difere do tempo para o mercado de duas formas: primeiro, pode medir o tempo que é atribuído a actividades específicas em oposição a só se referir a data de conclusão de um produto e, segundo, pode ser medido em numerodos pontos durante o desenvolvimento do projecto. Como ponto de referência para o negócio, faz sentido porque mede a capacidade de concluir mais projectos ou alocar mais tempo a projectos propostos. Paar além disso, quando o PMO possui uma boa medida de disponibilidade de serviço está em posição para redireccionar recurso para actividades no caminho crítico se for necessário. O PMO especiliza-se na disponibilidade de serviço através de standardização de actividade e planeamento de futuros projectos.

Se a equação acima tem um número mais baixo isso significa maior disponibilidade de serviço. Contudo, uma companhia deve ser cuidadosa para não ter tal quantidade de disponibilidade porque isso significa que tem recursos desperdiçados. Isto pode desbaratar tanto dinheiro como o que é desperdiçado num plano mal feito e mal gerido.

ROI

• ROI = (Rendimento – Investimento) / Investimento * 100

O PMO contribui para o ROI da companhia assegurando-se que os projectos são concluídos com sucesso e de acordo com as especificações definidas pelo cliente e stakeholders. Por isto, examinar o ROI como um KPI oferece uma vista incompleta à produtividade do PMO. Porque o PMO não influencia directamente o retorno financeiro. Antes oferece a estrutura através da qual poderemos construir o sucesso. O ROI, então, deve ser examinado em combinação com outras métricas para determinar a influência específica do PMO na performance global do negócio da companhia. O ROI pode ser usado para medir o sucesso, mas deve ser olhado projecto a projecto para determinar o impacto real do PMO.

Crescimento das Vendas

• Crescimento das Vendas = (Vendas correntes – Vendas anteriores)/Vendas anteriores

O PMO contribui para o crescimento das vendas de forma muito semelhante à sua influência no ROI. Faz isso oferecendo um ambiente que permite o crescimento das vendas sem muito esforço, muitas vezes através da melhoria das métricas nesta lista, como tempo para o mercado e disponibilidade de serviço. No entanto, a medida do crescimento das vendas não especifica a função do PMO nessa melhoria. Entretanto, melhorar o crescimento das vendas irá ser muito atractivo para os executivos de alto nível e, em particular, os CFO, porque é aquilo que os accionistas e investidores procuram numa companhia. Como tal, e apesar das óbvias limitações, o crescimento das vendas é uma métrica importante porque uma melhoria nesta área vai criar mais oportunidades financeiras para o negócio e poderá convencer muitos descrentes no PMO.

Utilização do Serviço

• Utilização do Serviço = Horas Facturadas/Horas Totais

Para além de reduzir e standardizar as actividades através do crescimento da disponibilidade do serviço, a utilização do serviço permite ao PMO garantir que o tempo está a ser usado com eficiência. Aqui, a utilização do serviço significa analisar os recursos alocados a um projecto e em particular os recursos humanos. Um PMO avançado será não só capaz de diminuir o número de pessoas que estão sobre e subutilizadas, mas será capaz de atribuir as pessoas para as actividades para as quais são os melhores, desta forma maximizando ovalor do seu tempo.

Aumentar a qualidade da utilização do serviço significa uma melhor qualidade do resultado do projecto na mesma quantidade de tempo. Isto irá optimizar a satisfação do cliente e dos empregados e irá garantir que o negócio está ao obter o melhor valor dos seus recursos e trabalho contratado.

______________

Demonstrar melhoria nestes KPI pode ajudar a mostrar o sucesso de um PMO da companhia. Em conclusão, o PMO ainda não foi aceite como necessário na maioria das organizações e é assim responsabilidade dele comprovar o valor que oferece. Deve repetir-se, contudo, que como o PMO é único, estes KPI devem ser olhados deforma específica para a companhia.

PMO e Métricas para o Sucesso

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

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

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

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

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

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

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

Para que serve a Timesheet?

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

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

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

Melhora a tomada de decisões

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

Ajuda na atribuição de recursos

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

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

Favorece a comunicação

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

As previsões são mais acertadas

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

As estimativas têm mais significado

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

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

Quanto tempo para implementar a ISO 27001

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

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

Tempo para as fases de PLANEAR e FAZER

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

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

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

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

As coisas que aceleram a implementação

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

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

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

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

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

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

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

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

LQ

O Controlo da Mudança

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

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

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

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

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

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

Durante o processo são utilizados dois documentos:

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

Propor uma mudança

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

Sumário do Impacto

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

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

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

Decisão

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

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

Implementar a Mudança

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

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

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

Fechar a Mudança

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