Cuidados finais com o processo

Continua de ‘Modelar o Workflow’)

Desenhar um processo exige trabalho e observação directa sobre um ou mais especialistas. Requer ainda atenção ao detalhe. Para o realizar temos de nos levantar e sair do gabinete para então realizar a análise das tarefas.

A parte que é talvez mais difícil é aceitar que não sabemos realmente o que se passa à nossa volta. Também é muito difícil observar imparcialmente uma pessoa a fazer alguma coisa que se julga que pode ser feita melhor sem se intervir – mas o objectivo é ser um observador imparcial. Se não consegue fazer isto então necessita de um profissional sem envolvimento para documentar os processos. O objectivo durante a análise das tarefas é documentar e não melhorar.

Parte da aprendizagem do que se faz na realidade é coleccionar todas as formas usadas por qualquer pessoa envolvida no processo que se está a estudar. Deve capturar ecrãs ou cópias físicas de dados de formulários usados. Tomar boas notas sobre a forma como são usados. Faça o mesmo para quaisquer «ferramentas» ou sistemas em uso.

Um princípio chave da ITIL é a eficiência – trabalhar melhor, não mais. Assim, a melhoria no tempo que leva a fazer as coisas é uma medida importante. Isto é muito conhecido na indústria e nos círculos dos recursos humanos, mas é também muitas vezes subestimado pelos gestores de TI que procuram a melhoria do fluxo do processo.

Para além da recolha das ferramentas em uso, é necessário capturar quanto tempo leva o trabalho a ser feito. Precisa de estar apto a responder à pergunta «quanto tempo leva a fazer isto?» antes de responder à questão «será que devo alterar isto?»

O valor de um modelo de processo exacto não pode ser incompreendido. Não se pode melhorar nada sem o compreendermos

Modelar o Workflow

Chegou a altura de fazer um gráfico de fluxo. Agora vê o que não pode fazer um gráfico de fluxos num gabinete ou sala de reuniões.

Pode modelar o fluxo de trabalho (análise da tarefa) através de um desenho ou utilizando símbolos de gráficos de fluxos.

Os símbolos comuns são:

	Início/Fim – Uma oval indica o início de uma tarefa ou uma conclusão. Um fluxo deve possuir só um ponto de partida mas poderá ter muitos pontos de fim. Como por exemplo o início do processo de Gestão de Problemas.
	Input/Output – Um paralelograma indica um input ou um output. Seguindo o exemplo da Gestão de Problemas um input é o Registo de um Incidente. Um output pode ser o Registo de um Erro Conhecido. Normalmente, um output torna-se o input de outro processo ou cadeia de eventos.
	Processo/Procedimento – Um rectângulo indica um procedimento simples. Isto é, tecnicamente, denominado um processo, mas não fique confuso com o processo ITIL e o símbolo de processo num gráfico de fluxos. Estes processos não incluem decisões. Seguindo o exemplo, um processo de gráfico de fluxos pode ser a revisão de Incidentes associados com o registo de problemas.
	Decisão – Um losango indica uma decisão e o fluxo de saída deste símbolo pode ser outra cadeia de Início/Fim, input/output, processo/procedimento e símbolos de decisão.

Pode simplesmente usar um desenho com texto se quiser. O que é importante é documentar o que acontece tão completamente quanto possível e produzir o seu modelo tão cedo como possível depois de recolher todos os dados possíveis.

Agora precisa de criar o modelo e deve fazê-lo no mesmo dia em que recolheu a informação. Isto é devido a não termos, de facto, conseguido apontar toda a informação! O que tem em mente é exactamente a cola que permitirá documentar o que aprendeu – se esperar para escrever irá perder detalhes vitais do processo.

Quando cria o seu modelo, faça-o utilizando ‘blocos’ simples e compreensíveis. O que permitirá que qualquer pessoa siga o fluxo do processo, especialmente os que não estão familiarizados com este. Para já, não inclua tempos no fluxo, concentre-se no trabalho, já que os tempos podem ser adicionados depois.

Tente desenhar o modelo da esquerda para a direita, com outras actividades dentro do processo ‘a descer’ dos blocos do topo. Tente evitar, na medida do possível, a duplicação e os cruzamentos.

Faça a revisão do seu gráfico com o especialista e, depois, reveja de novo o gráfico. Quando se sentir satisfeito e que o gráfico representa com exactidão o que se passa (não aquilo que você pretende), pode voltar e adicionar os tempos.

Esteja pronto para uma surpresa – ficará provavelmente, espantado com a quantidade de trabalho e o tempo envolvido. Só agora pode pensar acerca da ITIL, e agora pode melhorar o seu fluxo do processo.

Andar o caminho

(Continuação de ‘Fluxo Real versus Fluxo Imaginário’)

O seu propósito é observar o fluxo total e isso toma tempo. Por exemplo, consideremos o Service Desk, pode necessitar de algumas horas para observar como são respondidas as chamadas, as tarefas envolvidas, os atrasos, períodos de espera, uso de ferramentas, documentação acedida, movimentos físicos, etc. Outros processos podem ainda levar mais tempo. O objectivo exige exactidão e detalhe, leve algum tempo.

Observe o especialista seleccionado. Aproveite algumas destas dicas:

Assegure-se de que quem está a ser observado sabe o que você está a fazer e porquê – eles são os especialistas e você quer fazer como eles fazem as coisas funcionar,

• Foque-se no normal ou no trabalho de rotina e não nas excepções
• Observe mais do que uma repetição do trabalho
• Escreva imediatamente as coisas importantes
• Seja meticuloso e atento com os detalhes
• Não interrompa o especialista, não o critique ou tente corrigir.

Necessita capturar o ’quem, quê, como e quando’ do processo e deve deixar passar o ‘como e porquê’ para já. Tente então registar durante análise de tarefas:

• Quem está a fazer o trabalho e como muda cada vez que a pessoa deixa de trabalhar
• O que é feito em cada passo do processo
• Quando o processo se inicia, qual é o tempo necessário para realizar cada tarefa principal e quais os atrasos
• Onde está localizado o trabalho no início do processo e para onde vai
• Quando tiver todos os factos precisa desenvolver um gráfico de fluxos do processo para modelar o workflow.

Fluxo real versus imaginário

(Continuação de ‘As Verdades do Controlo de Processos’)

Já que temos que aceitar que nem você nem a sua equipa compreendem realmente o processo que quer redesenhar, então o primeiro passo é aprender de novo o que se consegue determinar do processo.

A única forma de descobrir o que está a fazer é sair de detrás da secretária, sair do gabinete e passear, observar e tomar notas. Não se pode praticar ITIL atrás de uma secretária. Esta afirmação parece simples e alguns até pensam que já actuam assim, mas como em muitas outras coisas, fazer isto não é tão directo. Para praticar ITIL você tem de caminhar, literalmente, através do processo.

Para ter sucesso tem de compreender a diferença entre o que é esperado e o que acontece na realidade para perceber os factores e variáveis envolvidas. Só quando compreender o fluxo real do processo pode melhorá-lo e alterá-lo.

A sai missão aqui é não impor a conformidade, mas antes compreender porque é que o trabalho está ser realizado desta forma. Note que não estou a dizer “porque é que o trabalho está a ser feito da forma errada” – e aqui está a chave – o trabalho está a ser feito de acordo com aquilo que tem de ser feito, não com aquilo que você pensa que deve ser. Nesta etapa, não é produtivo atribuir culpas e etiquetas como «certo» ou «errado».

Muitos gestores sentem que devem reunir um grupo de colaboradores e construir ou documentar o fluxo do processo como um grupo de processos. Ora, isto não está certo, porque é só um exercício de imaginação. A experiência e as boas práticas mostram que este método leva sempre muito mais tempo e resulta numa compreensão incompleta.

Contudo você pode ter um cúmplice interessado na sua avaliação do processo – um perito da área em questão. É muito mais fácil modelar um processo com base na observação de um participante motivado. O especialista pode ajudar a reduzir a quantidade de informação que é necessário registar e pode validar e/ou explicar a lógica por detrás de muitas acções. Lembre-se que a maioria dos especialistas não sabem por eles porque é que fazem as coisas que fazem.

Aprenda a realizar uma análise de tarefas, se possível localize e seleccione um especialista e de seguida percorra o processo, tome notas acerca do fluxo e das actividades. Comece esta avaliação com o processo mais comum. Anote as excepções àquilo que você pensa que é «correcto» mas não pare nem interrompa o especialista enquanto este trabalha, em vez disso tome notas e reveja as excepções mais tarde com o especialista.

Lembre-se sempre que o seu propósito é coleccionar e modelar o processo existente como funciona hoje; não aquilo que você imagina que deve ser, mas antes as tarefas reais e o fluxo que está a trabalhar.

(Continua)

As verdades do Controlo de processo

Aquilo que deve aceitar, em primeiro lugar, é ninguém realmente conhece o que se está a fazer e como é que as pessoas realizam o seu trabalho, nem os trabalhadores nem os gestores.

Pode parecer óbvio que quanto mais alta é a função de gestão menos se como compreende verdadeiramente como é realizado o trabalho. Contudo, não só os gestores muitas vezes não têm ideia como os processos são realizados, como muitos dos trabalhadores também não vos conseguem dizer quando lhes é perguntado.

Centenas de anos de melhorias nos processos de fabrico permitiram realçar dois factos acerca do fluxo de trabalho (workflow). Primeiro, só aqueles que realizam as tarefas de trabalho têm as competências para realizar o trabalho; e, segundo, não pode perguntar ao trabalhador o que está a fazer, já que ele interiorizou muitas das competências das tarefas.

Por outras palavras, só aqueles que estão a fazer o trabalho sabem como fazê-lo e não lhes pode perguntar acerca do trabalho porque não estão conscientes de todos os pequenos passos. Esta questão fundamental de desconexão vem ocorrendo em todos os programas de melhorias de processos desde o princípio do controlo dos processos.

Os profissionais de Recursos Humanos denominam documentação à análise de tarefas realizada por um profissional de análise de funções. Nesta análise profissional das tarefas observa-se o perito do assunto em questão e regista-se o que ele está a fazer. Não se pergunta o que ele planeia fazer, mas antes se regista o que ele, na realidade, fez.

Se lhes pedimos para escreverem o que estão a fazer isto irá resultar em processos incompletos e fraca documentação de fluxo de trabalho.

Verificamos depois que estes passos «perdidos» são elementos chave do fluxo de trabalho e esconderam verdadeiras questões ou oportunidades. Comece por pôr de lado ideias pré-concebidas sobre o que está «certo» e «errado», antes clarificando os propósitos e o que se espera ser realizado no resultado final.

Independentemente do pensa que sabe, o trabalho que realmente está a ser feito e como é realizado é diferente. Esteja preparado para grandes surpresas!

Como desenhar processos

A prática da ITIL não faz simplesmente atrás de uma secretária. Antes que possa melhorar um processo, tem de compreender o processo existente. Tem de sair de detrás da secretária e percorrer o processo, o que até parece simples, mas como muitas outras coisas, fazê-lo não é tão imediato…

Sabemos que a IT Infrastructure Library® ITIL® descreve o que é necessário fazer. A ITIL só descrever os modelos de processos e não oferece direcção passo a passo. A ITIL é uma orientação que deve ser interpretada e adaptada antes da utilização.

Os processos descrevem o trabalho realizado por pessoas. Praticar a ITIL assim torna-se uma ideia simples: compreender os processos existentes (workflow), compará-los com os modelos ITIL, adaptar, improvisar e ultrapassar!

Os processos de TI são muitas vezes transversais a mais do que um silo e, assim, é muito difícil encontrar um colaborador ou um gestor que conheça de verdade o fluxo fim-a-fim do processo.

Esta realização é fundamental para o vosso sucesso na prática da ITIL – como funciona o processo corrente é muitas vezes diferente de como pensamos como é (ou deveria) trabalhar.

Proximamente indicarei alguns passos que podem ajudar no desenho ou redesenho dos vossos processos.

Precisamos de compreender os nossos processo!

Os fracassos nas Transformações nas TI

Estou a iniciar um processo de formação de recursos humanos para uma organização pública em África, com o intuito de permitir a iniciação de um processo de transformação da gestão do serviço de TI. O que vou fazer é só o início de um processo de transformação e nem sequer o seu lançamento, somente a realização das condições prévias.

Eu cuidados teremos para evitar o fracasso nos processos de transformação?

Os processos de implementação de boas práticas em gestão de TI devem ser ponderados e compreendidos para garantir efeitos efectivos. O que acontece, na realidade, é que estes processos são muitas vezes mal preparados, pior acompanhados e pouco verificados e então falham. Vamos abordar alguns desses factores.

Porque é que as organizações decidem transformar os seus processos de TI? É quase sempre devido a um evento externo (i.e., regulação, competição, nova liderança) que desencadeia a transformação, mas independentemente da causa, todas as transformações têm as mesmas premissas básicas:

• O que é que é necessário mudar?
• Porque é que é necessário mudar?
• Quem sofrerá o impacto da mudança?
• Quando estará concluída a mudança?

Mas, quais são as razões comuns de falha nas transformações de TI?

Visão Partilhada do Sucesso

Uma das primeiras razões é a falta de uma visão partilhada comum. Esta visão inclui objectivos de negócio, estado final desejado e como esta mudança irá melhorar o negócio. Muitas vezes o líder possui uma visão clara e concisa das mudanças requeridas, mas não é capaz de as articular para a organização. As comunicações entre o líder e as suas “tropas” ficam perdidas no meio das camadas intermédias de gestão.

Quando se pretende modificar significativamente uma organização, todas as pessoas devem conhecer a visão, compreendê-la e aceitá-la (claro que isto vai-se obtendo paulatinamente no processo). Uma forma de resolver este problema é saltar por cima da cadeia de gestão e falar directamente com as “tropas”. Isto pode ser alcançado de várias formas: reuniões gerais, newsletters, email, sms, etc. Um aspecto chave é garantir que todos recebem a mesma mensagem e que esta não está a ser distorcida. Para os líderes de uma transformação o mais importante é comunicação, mais comunicação e, depois, comunicação.

Comunicar, comunicar, comunicar

Outra causa comum de fracasso nas transformações das TI é aquilo a que chamamos a resistência passiva. O que significa isto? Muitas a razão PORQUE uma transformação é necessária é mantida ao nível da direcção e não é partilhada com os outros níveis e com o pessoal. Ou, só são partilhadas algumas das razões para a mudança. Mesmo quando esta informação é partilhada, muitas vezes não é entendida pelo pessoal. Eles não têm o mesmo acesso a outras fontes de informação como a equipa de direcção e eles também não têm a mesma perspectiva.

A razão para a mudança deve ser colocada em termos tais que todas as pessoas possam relacionar-se com ela. Sem esta compreensão, as pessoas irão conformar-se com as “ordens” para mudar e na realidade, nunca irão aceitar de verdade a mudança. Ninguém se irá activamente opor à mudança, mas não iremos ter apoiantes activos ou agentes de mudança para assistir nas actividades.

Uma abordagem para evitar esta armadilha é envolver pessoas de todos os níveis em comunicações de dois sentidos. Ofereça ao pessoal a oportunidade de colocar as questões e perguntas acerca dos porquês da mudança, da sua necessidade, e permitir-lhes alcançar uma compreensão em sintonia com a equipa de liderança. Esta compreensão não acontece de um momento para o outro, irá levar tempo. Então necessita comunicar, comunicar e comunicar.

As Métricas ajudam a acontecer

Outro problema que a maioria dos esforços de transformação enfrenta é que ninguém está a seguir as melhorias. Sim, eu sei que todos os esforços têm um plano de projecto e uma escala de tempo e isto vai sendo reportado, mas até que ponto as mudanças estão a melhorar os resultados do negócio? Muitas vezes, o plano de projecto é utilizado para determinar em que medida o projecto progride e as pessoas não sabem na realidade se as melhorias estão a ter o desejado efeito.

O desenvolvimento de métricas é visto tão só como um subcomponente do projecto. De facto, deverá ter a mesma importância como o desenvolvimento dos Objectivos de Negócio. O desenho, recolha e acompanhamento destas métricas é muitas vezes realizado pela equipa de projecto. Se existem múltiplas equipas fazendo mudanças, usualmente cada equipa tem a sua abordagem para métricas de desenvolvimento o que resulta num conjunto de métricas descoordenadas. O que é que acontece quando o projecto termina e as equipas voltam às suas origens? Uma abordagem muito melhor é ver o desenvolvimento de métricas como um esforço separado mas apertadamente ligado às equipas de mudança.

Um grupo separado deverá reunir os requisitos em que se baseiam os objectivos de negócio e garantirá que estas mesmas métricas fornecem uma informação útil para todos os níveis de gestão. Depois de ser alcançado um acordo de que estas são as métricas “certas”, esta equipa deverá implementar as métricas e fornecer uma análise continuada e supervisão. Como estas métricas deverão comprovar a melhoria do negócio, devem continuar mesmo depois das equipas de projecto serem desmobilizadas. Se o que se passa não está escrito, então não aconteceu. A norma ISO 20.000 declara que se não é acompanhado e medido, então não irá acontecer.

A regra dos 80/20

O último tópico daquilo que liquida os esforços de transformação das TI é o tempo. Qualquer esforço sério de transformação tomará entre 12 a 24 meses para ficar concluído. Muitas das vezes, as melhorias de negócio não são tão óbvias senão quando o programa está quase terminado. Isto significa que já passou um ano desde que foi requerida a mudança e a altura em que foi implementada. Neste ano, ainda para mais, o ambiente já não é o mesmo e o impacto de quaisquer mudanças é inferior ao esperado. Muito provavelmente, as pessoas que esperavam a mudança implementaram medidas transitórias e temporárias para obter melhores resultados. Então por que leva tanto tempo a ver os resultados? Bem, quase todos os programas de transformação procuram quase a perfeição. Este é um programa grande e visível e eles querem que tudo corra bem para todos. Então o que podemos fazer para resolver isto?

Por natureza um Programa de Transformação é grande, complexo e longo. Mas este programa pode ser decomposto em pequenos subprojectos, que podem ter resultados concretos em 90 a 120 dias. Mais importante ainda, estes resultados NÃO tem de ser perfeitos. Utilizamos uma filosofia prática para obtermos 80% certo. Acima de tudo, uma melhoria de 80% em 90 dias é melhor que nenhuma melhoria em 1 ano. Os primeiros subprojectos devem apontar a melhorias já prontas a serem implementadas, coisas que são fáceis e rápidas de implementar. Desta forma, a sua equipa de mudança instila confiança nos seus clientes, na liderança de topo e, o que é mais importante, neles próprios. Este será um esforço longo e se nos sentirmos bem no início poderemos caminhar ate muito mais longe.

Em Suma

Para proceder a uma transformação da Gestão de Serviços de TI, é necessário o conhecimento e a vontade mas temos de estar atentos a:

• Possuir uma clara visão da mudança que é comunicada de forma contínua e consistente e todos.
• Garantir a compreensão e aceitação das razões para a mudança por todos.
• Criar e implementar métricas ligadas aos resultados de negócio desejados.
• Seja rápido e ágil com os resultados intermédios que estejam 80% certos.

A Verdade e nada mais que a Verdade

Uma das responsabilidades mais importantes do gestor de projecto é o continuado reporting sobre o projecto. Esta comunicação com todos os stakeholders, desde os administradores até aos membros da equipa de projecto é muito importante para manter todos bem informados.

Há cinco pontos importantes neste reporting:

Status do Projecto

Deve ser produzido semanalmente um relatório de status do projecto, onde será mostrado o planeado relativamente ao esforço realizado, a percentagem de conclusão e o orçamento financeiro relativamente ao custo incorrido. Também pode querer incluir um sumário das actividades para a semana seguinte, próximas milestones e resultados.

Agendamento do projecto e actividades completadas

Regularmente deve apresentar ao dono do projecto, ao sponsor e outros stakeholders o progresso das actividades projectadas. Produza uma vista sumarizada de todas as actividades com a percentagem de conclusão. Pode querer adicionar este relatório como apêndice do relatório de status semanal.

Milestones

As Milestones são muito importantes nos projectos, já que mostram quando os principais resultados são realizados e entregues. O relatório mostra a percentagem de conclusão de cada milestone e a data planeada de conclusão. Também é muito bom em termos motivacionais para manter os membros da equipa focados, já que estes são os objectivos do projecto e todos gostam de alcançar os seus objectivos ainda mais do que a conclusão das actividades individuais.

Obter apoio

Os stakeholders a um nível executivo não gostam de estar sempre a ouvir que tudo vai bem com o projecto. Antes necessitam de saber a verdade relativamente ao projecto e se ele está a fugir ao planeado, saberem qual a razão, comunicando isto o mais cedo possível. 
Não tenha receio de pedir apoio e assistência às pessoas certas, tal como o sponsor do projecto ou mesmo o cliente, para recolocar o projecto no caminho certo. Garante que lhes deixe que eles sabem tudo o que necessitam, seja sobre finanças, recurso ou tempo. Desta forma envolvê-los-á no projecto e eles sentir-se-ão mais confortáveis porque sabem exactamente aquilo que está a acontecer no projecto.

A verdade e nada mais que a verdade

O reporting do seu projecto deve a todos os níveis reflectir a mesma informação sempre. Isto é algumas vezes referido como «uma só versão da verdade» e desenvolve um sentimento de controlo entre todos os stakeholders, já que todos vêem exactamente a mesma informação nos diferentes níveis.
Para além destas orientações no reporting não se esqueça que deve preocupar-se com os relatórios de qualidade durante o curso de todo o projecto.

PMO – Que tipo definir?

Durante dois dias estive reunido com alguns daqueles portugueses que, aonde no mundo trabalham, deixam uma imagem de rigor e grande competência. São gestores de projecto de topo numa empresa multinacional e discutimos a forma como se organizam. Da discussão concluímos, que o tipo de estrutura de gestão de projecto é importante, mas mais do que a estrutura há questões que são essenciais para se obter o sucesso.

Não é na estrutura do PMO que o sucesso se irá alicerçar, antes o mais importante está na adopção de práticas na empresa. O PMO só contribuirá para a sua implementação

Existem, em termos gerias 3 tipos de organizações para o Project Management Office (PMO), variando no grau de controlo e influência que têm nos projectos realizados pela organização.

1. PMO de Suporte

O PMO de suporte geralmente oferece apoio na forma de experiência técnica, modelos, boas práticas, acesso a informação e experiência de outros projectos e outras similares. Este tipo de estrutura funciona bem numa organização em que os projectos são realizados com sucesso de uma forma controlada e onde um controlo adicional é considerado desnecessário. Também, é suficiente quando o objectivo é possuir uma espécie de «repositório» de informação de gestão de projecto de toda a empresa para ser utilizada de forma livre pelos gestores d projecto. Se estes são os propósitos então o PMO de suporte é o indicado.

2. PMO de Controlo

Em organizações onde o desejo é «reinar» sobre as actividades, processos, procedimentos, documentação e mais – sera um PMO de controlo que conseguirá alcançar o objectivo.

Não só requer o apoio da organização, como exige que o suporte seja utilizado pelos interessados. Os requisitos podem incluir a adopção de metodologias específicas, modelos, formulários, conformidade com a governação e ainda a aplicação de outras regras controladas pelo PMO. Adicionalmente, este tipo de projectos podem ter a necessidade de passar um conjunto de revisões realizadas pelo PMO de controlo, o que podem representar um factor de risco adicional para o projecto. Mas esta situação é funcional só se:

a) A conformidade com as ofertas de gestão de projecto é assumida de forma completa e traz melhorias à organização e à forma como são executados os projectos;

b) O PMO tiver o suporte executivo adequado e suficiente para colocar por detrás dos controlos colocados em posição.

3. PMO Directivo

Este tipo de PMO passa além do controlo e na realidade «toam conta» dos projectos ao fornecer a experiência de gestão de projecto e os recursos para gerir o projecto. Conforme as organizações iniciam os projectos, os gestores de projectos profissionais são designados do PMO para os projectos. Esta solução injecta uma grande quantidade de profissionalismo aos projectos e, como cada gestor do projecto vem do PMO e reporta a este, é assegurado um alto nível de consistência de práticas entre os projectos. Isto é muito efectivo em grandes organizações que normalmente têm apoio em várias áreas e assim esta opção ajusta-se bem à respectiva cultura.

O melhor tipo será aquele que for mais específico para a organização, cultura e história, no que toca a funcionar bem ou não funcionar. Mas os objectivos são sempre, mais ou menos, estes:

1. Implementar uma metodologia comum
2. Standardização da terminologia
3. Introdução de processos de gestão de projectos efectivos e repetíveis
4. Fornecer ferramentas comuns de suporte
5. O objectivo último é melhorar os níveis de sucesso dos projectos na organização

Só quem estiver atento a estas questões consegue atingir o devido equilíbrio da estrutura do seu PMO para alcançar consistentemente o sucesso dos projectos.

Criar um Charter para o Projecto

Um dos processos mais críticos no Ciclo de Vida do Projecto é o da criação de um Project Charter (Charter do Projecto). De facto, sem este documento, o projecto é um navio à deriva. Não temos mapa para nos orientar para a direcção certa!

O Charter do Projecto descrever a visão, objectivos, âmbito, organização e plano de implementação do projecto de forma sucinta. Isto irá ajudar a estabelecer uma direcção para o projecto e a obter o suporte dos stakeholders relativamente ao propósito, à forma como será organizado e implementado. Apoiará ainda no controlo do âmbito do projecto ao definir exactamente o que deve ser alcançado (e, muitas vezes, também aquilo que está fora do âmbito). O que devemos então fazer para definir o Charter do Projecto?

Identificar a Visão do Projecto

Visão: O primeiro momento é a identificação da visão do Projecto. Esta visão envolve o propósito do projecto e é o fim definido a meta visualizada para o projecto.

Objectivos: Com base na visão declarada faça uma lista com três a cinco objectivos a serem alcançados pelo projecto. Cada objectivo deve ser específico, mensurável, realista e ligado no tempo.

Âmbito: Possuindo uma clara visualização da Visão e dos Objectivos do projecto, agora é tempo de definir o âmbito do projecto. O âmbito define as fronteiras formais do projecto através da descrição da forma como o negócio será mudado ou renovado através da entrega do projecto.

Resultados: Necessitamos, seguidamente, de descrever cada um dos resultados que irão ser produzidos pelo projecto.

Descrever a Organização do Projecto

No momento seguinte teremos de identificar como será estruturado o projecto discriminando os clientes, stakeholders com as suas funções e responsabilidades e as linhas do necessário reporting.

Clientes: Primeiro vamos identificar os clientes do projecto. Um cliente é uma pessoa ou entidade que é responsável por aceitar os resultados quando o projecto está completo.

Stakeholders: É uma pessoa ou entidade dentro ou fora do projecto com um interesse chave específico ou uma posição no projecto, Por exemplo, o Controller Financeiro pode estar interessado no custo do projecto e o CEO estará interessado em até que ponto o projecto ajuda a alcançar a visão da companhia.

Funções: Deverá ser feita a relação das funções envolvidas na realização do projecto. Exemplos de funções são Sponsor do Projecto, Conselho do Projecto e Gestor do Projecto. Faça o sumário de cada uma das responsabilidades primárias de cada uma das funções identificadas.

Estrutura: Logo que exista uma visão clara das funções necessárias para realizar o projecto, poderão ser definidas as linhas de reporting entre estas funções dentro de um Diagrama da Organização do Projecto,

Planear a Abordagem de Implementação

Tem já uma definição sólida do que deve ser realizado pelo projecto e como será organizado para ser alcançado, então, o próximo passo é descrever a abordagem de implementação da seguinte forma:

Plano de Implementação: Para oferecer confiança ao Cliente e aos Stakeholders de que a implementação foi bem pensada ao longo do processo, é criado um Plano de Implementação listando todas as fases, as actividades e as escalas de tempo envolvidas na realização do projecto.

Milestones: Para além disso, devemos definir qualquer milestone importante e descrever por que é que estas são críticas para o projecto. Uma milestone é tipicamente um evento importante do projecto, como por exemplo uma realização ou um resultado chave.

Dependências: Registe todas as dependências e a sua importância para o projecto. Uma dependência é definida como uma actividade que irá provavelmente ter impacto no projecto durante o seu ciclo de vida.

Plano de Recursos: Crie um plano que sumarize os recursos envolvidos na realização do projecto listando o trabalho, equipamentos e materiais necessários. Depois orçamente os recursos financeiros necessários.

Pondere os Riscos e Problemas

O passo final a tomar para completar o Charter do Projecto é identificar qualquer risco, problema, assumpção e constrangimento relacionado com o projecto.

Pode descarregar aqui um modelo de Charter de Projecto.

Se completar todos estes passos então terá criado um sólido Charter de Projecto. Este irá ajudá-lo a gerir o âmbito e a preparar um plano que consiga realizar o projecto dentro do orçamento e em tempo.

Ver Também:

• Processos que apoiam o sucesso em projecto
• O que é a WBS?
• Os grupos de processos

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.

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.

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)

As Cinco Regras de Ouro da Gestão de Projecto

Regra nº 1 – A Gestão do Tempo é Crítica

Para oferecer os resultados do projecto em tempo necessita de gerir com cuidado o tempo. Pra fazer isto, assegura-se de quie cada actividade está listada no Plano do Projecto e que estão agendadas para ocorrerem com precisão quando você delas necessita.

Todas as semanas, actualize o seu plano com o tempo gasto na conclusão das actividades e identifique todas as tarefas que estejam atrasadas relativamente ao plano. Controle a percentagem de conclusão para cada actividadee se estiver atrasada, coloque-a no plano atribuindo ou mais recursos ou reduzindo a dimensão da actividade. Não permita que as tarefas escorreguem. Esteja vigilante.

Regra nº 2 – Controle os Custos e faça a Gestão das Finanças

Cada elemento dop seu projecto incorre num custo. Identifique todos os custos planeados desde o início e obtenha aprovação para estes do gestor de topo.

Registe, então, todas as despesas conforme vão ocorrendo – incluindo pessoas, equipamento e materiais. Confirme que a despesa real não excede a despesa planeada. Se tal ocorrer, então tem de cortar. Se ultrapassa o orçamento, comunique a situação cedo ao seu Sponsor de Projecto.

Regra nº 3 – Garanta que são Estabelecidas Metas de Qualidade

Tem de especificar logo no início, exactamente, o que irá o projecto ter como resultados. Logo de seguida, estabeleça as metas de qualidade destes resultados e obtenha a aporvação do cliente para estas metas de qualidade.

Cada semana, reveja a qualidade de cada resultado produzido pelo projecto. Se não estiver de acordo com o standard definido, resolva imediatamente. Nunca espere pelo fim do projecto antes de solucionar as questões da qualidade

Regra nº 4 – Controle o Âmbito ao Mais Baixo Nível

O seu âmbito é definido como «o conjunto de resultados que devem ser produzidos no projecto». Assegure-se, assim, que conhece o que é o seu âmbito, tente não deixar que ninguém o mude.

Todas as semanas verifique que a sua equipa está a trabalhar unicamente naquilo que deve ser produzido para o projecto e nada mais. Verifique se todos os resultados produzidos correspondem exactamente com a especificação definida para ele. Note que um aumento no âmbito do projecto irá fazer que seja mais difícil realizá-lo.

Regra nº 5 – Resolva Cedo as Questões

Se surgirem questões e dúvidas durante o projecto, então resolva-as cedo. Enfrente todas as questões antes que estas atrasem o projecto. Registe-as formalmente e depois acompanhe-as até que estejam solucionadas. Questões por resolver conduzem a atrasos que são a via para o insucesso do projecto. Ponha-se a salvo resolva cedo todas as questões.

Seleccionar uma Metodologia de Projecto

 

A questão é"o que é uma metodologia e como selecciono e implemento uma metodologia de gestão de projecto”?

"O Que é uma Metodologia"?

Uma metodologia é um processo passo a passo para realizar projectos. Descreve cada passo em profundidade para que possa saber o que tem de fazer para concluir o projecto. Ao seguir os mesmos passos para todos os projectos que realiza irá poupar tempo e esforço nos projectos.

"Como selecciono uma metodologia adequada?"

O primeiro passo é definir os requisitos necessários. Precisamos de pensar o que necessitamos obter com a nossa metodologia, qual o tipo de conteúdo que deve conter e qual a forma como deve ser utilizada.

Por exemplo os requisitos podem ser os seguintes:

· Deve conter um Ciclo de Vida de Projecto completo

· Cada passo neste ciclo de vida deve ser descrito em profundidade

· Cada passo deve possuir modelos práticos e exemplos para ajudar a completar este passo rápida e facilmente

· Necessita de estar baseado em standards globais de gestão de projecto

· Deve ser capaz de ser utilizado em projectos de todos os tipos e dimensões

· Deve ser fácil de adaptar.

O próximo passo é rever as metodologias que são usadas actualmente na sua organização. Porquê reinventar a roda se já há algum trabalho desenvolvido internamente? Procure qualquer metodologia de projecto utilizada e compare-a com os seus requisitos para ver se os cumpre.

Se não se encontra uma comparação adequada, então talvez tenhamos de procurar adoptar uma metodologia ou criar a mesma a partir das necessidades da organização. Por vezes, a aquisição de uma aplicação de gestão de projecto conforme às normas internacionais apoia na concretização do objectivo.

Se pensamos que a metodologia existente abrange cerca de 50% dos requisitos, então é bom. Mas certifique-se que consegue adaptar as restantes necessidades para cumprir os requisitos.

Se não tivermos nenhuma metodologia em funcionamento a solução será começar a criar uma desde o princípio. Será uma tarefa que irá consumir muito tempo e irá colocar a questão de adoptar uma metodologia pré-existente ou adquirir uma no mercado.

"Como implementar a metodologia seleccionada?"

Tenhamos adquirido uma ou construído a nossa metodologia, o próximo passo sera implementá-la na organização. Isto implica:

1. Criar um Plano de Implementação.

2. Customizar a metodologia para cada projecto.

3. Formar a equipa na utilização da metodologia.

4. Assegurar que a equipa segue a metodologia.

5. Melhorar continuamente a metodologia.

Aqui está! Através da selecção e implementação de uma metodologia para os seus projectos pode concluir mais rápida e facilmente as actividades.