Gestão de Requisitos – Maturidade da empresa

Passei os últimos dias a acompanhar alguns colaboradores de uma empresa que pretende preparar uma equipa para um desenvolvimento de alguma dimensão e necessita de compreender as necessidades do negócio e de as acompanhar ao longo do processo. Verifiquei, com algum espanto, que se pensa possível, de forma teórica, a preparação de recursos para implementar um processo de gestão de requisitos sem um prévio suporte de experiência e um cuidado consolidado no âmbito de anteriores projectos.
Pensei então que a empresa deveria tentar conhecer o estado e a forma como até agora este tipo de necessidade é encarada e que factores poderiam ser identificados para o realizar.
Em primeiro lugar, a realidade das empresas leva-nos considerar que:

1. Todas as organizações têm pontos negros – as pessoas focam-se naquilo que fazem muito bem e tendem a estar focados nestas questões e tentam sempre evitar melhorias. Muito embora isto pareça contra-intuitivo, quando se trata da maturidade da gestão de requisitos, já que aqui temos de procurar encontrar estes pontos negros – aquilo que não fazemos bem – e resolver isso para obter verdadeiros ganhos.
   
2. A maturidade da gestão de requisitos é definida de diversas formas, de uma forma elementar como possuir um conjunto estável de modelos de documentação usados pela companhia até um processo único dentro da organização definido com os recursos adequados e devidamente apoiado.

Então como podemos definir com simplicidade a maturidade da gestão de requisitos? A maturidade de um processo é sempre acerca do grau até ao qual uma organização pode ser repetível, consistente e eficiente na sua execução.
As organizações que não têm processos definidos, ou com processos mas que não são aplicados terão níveis baixos de maturidade, tal como as organizações com processos bem descritos, institucionalizados e optimizados terão altos níveis de maturidade. A questão é que não é só o processo que é necessário já que há seis capacidades a entender.

• Processo – Aquilo que as pessoas têm de fazer.
• Técnica – Como é que as pessoas irão realizar os vários passos do processo dentro de certas variações e condições.
  
• Competência dos colaboradores – As funções, papéis e competências das pessoas e o seu alinhamento para este objectivo correntemente e nas contratações futuras.
  
• Ferramentas/Tecnologia – O suporte e automação utilizados na conclusão das actividades.
  
• Organização – A estrutura de construção dos requisitos, a infra-estrutura de apoio, os serviços oferecidos pela organização e a abordagem de gestão dos recursos.
  
• Resultados – Os documentos, resultados e produtos do trabalho necessários para realizar o processo.

As pessoas falham aqui porque não vêem todas as capacidades que devem estar presentes. Um exemplo é o de uma organização com processos bem definidos e resultados, mas com um estabelecimento elementar das competências dos colaboradores necessárias e pouca formação para construir essas capacidades. Até que ponto será efectiva esta organização? Está a definir o que as pessoas devem fazer mas não está a dar as competências a estas pessoas para realizarem adequadamente as suas tarefas.
Se acredita que a sua organização tem uma maturidade elevada, então deve analisar as seis capacidades – para ver onde estão as fraquezas. A mais frágil é aquela em que se deve concentrar.
O outro erro que as pessoas fazem é pensar que os requisitos são só documentação ou só elicitação. De fato o “processo” dos requisitos é a realização de vários processos realmente importantes como:

• Planeamento e Gestão dos Requisitos
  
• Elicitação dos Requisitos (recolha)
  
• Análise e Documentação dos Requisitos
  
• Comunicação dos Requisitos
  
• Implementação dos Requisitos

Na realidade, a organização pode considerar-se madura porque é muito boa em uma ou duas destas áreas de processo, mas poucas organizações analisam todas as áreas de processo e compreendem as suas forças e fraquezas. Sublinho, que lá por sermos bons numa coisa, não significa que todo o processo é particularmente eficiente ou controlável e isso significa que não pode ser considerado maduro.
Alcançar a maturidade na gestão dos requisitos pode parecer complicado, mas é, em primeiro lugar, tratar de ser honesto com a visão que se tem da organização e aceitar que há sempre áreas que necessitam de melhoria. A maior parte do tempo, estas melhorias são em áreas que a organização «não vê» - são pontos cegos – e, mesmo muitas vezes, é necessário trazer pessoas de fora para avaliar … tal como auditores.
Por outro lado, as organizações que tem alta maturidade têm excepções, diferenças nos custos e variações de performance – mas tendem a conseguir produzir aplicações a 40% do custo das dos seus concorrentes com baixa maturidade. Qual é o investimento em TI que retorna 40% só por se ser honesto com nós próprios?
LQ

Como fazemos para os participantes prepararem uma reunião?

Todos participamos em reuniões em que os participantes deveriam ter lido um documento. ou realizado uma pesquisa ou feito qualquer tipo de «trabalho de casa» antes da reunião mas em que muito poucas pessoas, de facto, o fizeram.
Obviamente, o propósito deste trabalho prévio não é incomodar os participantes, antes garantir que todos estão preparados o que irá resultar numa reunião mais eficiente e mais rápida … certo? Não ERRADO!
A maior parte das vezes, se não todas, os participantes não concluem a tarefa conforme pedido e atrasam todo o grupo. Antes de organizar outra reunião, siga algumas orientações para a atribuição de trabalho prévio:

• Proponha o grupo a escolha da forma como realizar o trabalho de preparação (ou fora ou dentro da reunião). Pode dizer, «Todos terão de rever o documento antes da discussão. Podemos fazer isto em grupo e planear a reunião para um dia ou todos podem rever por si e o grupo reunirá duas horas para discutir as alterações. Qual é a abordagem que escolhe?». A maioria dos grupos irá optar por uma reunião mais curta. A técnica tende a ter sucesso porque o grupo tem a opção de rever o documento na reunião e opta por não o fazer.
  
• Atribua a participantes específicos a apresentação de secções concretas na reunião (o que lhes exigirá realizar trabalho prévio). Quando os participantes sabem que terão de liderar uma parte da reunião, responsabilizar-se-ão por se prepararem. Ninguém gosta de mostrar-se mal preparado.
  
• Proponha trabalhos curtos. Quanto mais complicados são, mais difícil será serem realizados.
  
• Peça para que os participantes formulem uma lista de dúvidas ou questões sobre o trabalho «de casa», antes da realização da reunião. Isto irá funcionar como uma confirmação sobre a realização desse trabalho prévio. Se não houver feedback de alguém da equipa, telefone-lhe para solicitar a resposta.
  
• Dê aos participantes tempo suficiente para realizarem esse trabalho prévio. O melhor é deixar a equipa definir o tempo que necessita para concluir o trabalho. Esta participação aumenta muito a probabilidade de realização.
  
• Discuta o problema com os participantes que não se prepararam, durante a fase final da reunião, e encoraje a equipa a encontrar abordagens de futuro para tratar desta questão.

Como desenhar processos – Versão completa

A versão total do artigo sobre o desenho de processos ITIL.

1. 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… >>>

2. As verdades do controlo do 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…. >>>

3. Fluxo real versus fluxo imaginário

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. >>>

4. Andar o caminho

O seu propósito é observar o fluxo total e isso toma tempo. >>>

5. 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. >>>

6. Cuidados finais com o processo

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. >>>

Estou à vossa disposição para esclarecimentos ou dúvidas. Em breve, continuamos com este tema.

Luís Quintino

A Gestão de Tempo em Projecto

A área de conhecimento de Gestão do Tempo refere-se vulgarmente às competências, ferramentas e técnicas usadas para gerir o tempo quando se realizam actividades específicas, projectos e objectivos. Para nos tornarmos num em efectivos gestores de tempo, devemos ser capazes de compreender com clareza as actividades do projecto e ter a competência necessária para estabelecer o plano, agendamento e controlar a linha de tempo de um projecto. Além destas competências, devemos ainda ser capazes de utilizar ferramentas de gestão de tempo que nos ajudam a analisar, medir e avaliar as suas técnicas de gestão de tempo. Vejamos os quatro passos da gestão de tempo:

1. Definir as actividades
2. Sequenciar as actividades
3. Estimar os Recursos da Actividade
4. Desenvolver e controlar o Agendamento.

Definir as Actividades

Temos aqui de definir as actividades, milestones e outras necessárias à conclusão do projecto. Inicie com uma definição básica de cada actividade e preencha os detalhes conforme o projecto vai ganhando forma.

Um gráfico de Gantt é uma forma simples e rápida de desenhar todo o projecto. Use o gráfico para adicionar actividades e a sua duração estimada. Não de preocupe com datas neste ponto do processo, antes foque-se no tempo que irá necessitar para concluir cada uma das actividades individuais.

Sequenciar as actividades

Logo que considera que as actividades essenciais estão definidas, pode começar a ordená-las. Sem preocupação pelas datas, ordene-as da forma que tem mais sentido para si. Crie subactividades e organize o projecto de uma forma lógica.

Logo que tenha todas as actividades ordenadas adicione dependências para cada actividade. A utilização de dependências em vez de datas ajudará a ver a verdadeira linha de tempo do projecto. Se está a construir uma casa os alicerces devem vir antes da construção das paredes, já que aquele é um requisito do suporte desta.

Estime os recursos da actividade

Chegámos ao passo mais desafiante deste processo porque exige que avalie a oferta e procura de cada recurso/pessoa e como é que estes se relacionam com o seu projecto específico. Será que tem recursos disponíveis e suficientes para completar a atribuição conforme agendado ou necessita de recursos adicionais?

Atribua pessoas concretas ou funções a cada actividade e reveja as dependências com base na alocação de recursos. Veja as alocações que determinam alongamentos do agendamento e aquelas que representam sobre alocação para determinar se necessita de contratar recursos.

Desenvolva e controle o agendamento

Se utilizou um gráfico de Gantt para criar a linha de tempo do projecto, será muito fácil desenvolver o agendamento do projecto. Reveja o gráfico de Gantt com toda a sua equipa e assegure-se que todos o reconhecem antes de iniciar o projecto. Para além disso, todos devem compreender o seu papel no projecto e devem estra aptos para se comprometerem conscientemente com a escala de tempo.

O controlo do agendamento é bastante mais difícil do que o planeamento do agendamento e exige muita mais gestão de um para um do que está à espera. O gestor do projecto deve monitorizar com cuidado o status do projecto e verificar que as actividades a serem completados estão dentro do âmbito e do tempo definido.

Nota: Muitas companhias orientadas aos serviços podem requerer que o tempo usado para cada actividade seja registado. Garantir que as horas são introduzidas quando uma actividade está concluída poupará imenso tempo e dores de cabeça quando tiver de ser enviada a factura.

Uma ferramenta integrada de gestão de projecto será aqui de grande utilidade.

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!

Conflitos em Projecto

Os conflitos em equipas de projecto são uma constante. Só em ocasiões muito raras não ocorrem conflitos – mesmo nos projectos mais pequenos os conflitos agigantam-se. Decorrem da natureza humana existirem conflitos e estes decorrem de muitas razões, entre as quais: fogem

• Incompreensões
• Choques de personalidades
• Diferenças de opinião acerca da forma de abordagem do problema
• Egos.

Como gestor de projecto, parte das suas responsabilidades inclui a gestão de conflitos na equipa de projecto. A melhor forma de gerir um conflito é garantir que as partes envolvidas são aquelas que podem desenvolver a solução. Não pode soluciona-lo no lugar deles; eles têm de chegar a um acordo sobre a forma de eles resolverem o conflito.
Tenha presente que algumas vezes o conflito não pode ser resolvido. Por exemplo, pode ter dois colaboradores na equipa de projecto que simplesmente não conseguem dar-se bem faça-se o que se fizer – já aconteceu demasiado entre eles. Se não pode ajuda-los a resolver o conflito, eles devem, no mínimo, trabalhar profissionalmente entre eles para o bem da equipa e do projecto. O seu trabalho, neste caso, é ajuda-los a encontrar uma forma de eles se relacionarem no projecto de forma cordial e profissional entre eles.
Algumas soluções para o ajudar a assumir a direcção mais apropriada:

• Marque uma primeira reunião com os colaboradores que estão a ter o conflito para discutir:
• Quais são as questões? Ponha tudo em cima da mesa – deixe-os discorrer.
• Quais são as perspectivas deles?
• Trabalhe com ambas as partes para desenvolver critérios para a solução do conflito deles.

Pergunte-lhes qual a forma que eles pensam que permitirá ultrapassar a questão, ou pô-la de lado, com base no critério de resolução com que eles acordaram, de maneira a ultrapassar e pô-los a trabalhar em conjunto. Será que existem outras alternativas? Isto deverá permitir que eles pensem sobre o assunto durante a noite.
Agende pelo menos uma ou duas horas para a primeira reunião (conforme a extensão da questão). Explique durante esta reunião como está este conflito entre eles a afectar o projecto e a equipa como um todo.
Se necessário marque nova reunião no dia seguinte para reavaliar as ideias a que chegaram. O propósito é levá-los a, pelo menos, comunicarem e trazerem tudo para a discussão. Tem de se assegurar que eles estão realmente a ouvirem-se um ao outro. Lembre-se que a confidencialidade é a chave e recorde-lhes que nada do que se passa na reunião deve passar para fora da sala.
Em alguns casos, pode ser útil reunir com as partes individualmente para os ajudar a pensar como podem abordar uma resolução para o conflito.

• Será que eles conseguem chegar a um consenso com as alternativas?
• Lembre- se que, por vezes, nenhum consenso pode ser alcançado e o conflito não tem resolução. A questão será saber como poderão eles trabalhar profissionalmente e cordialmente até à conclusão do projecto?

Logo que um consenso é gerado ou é obtido acordo para trabalharem em conjunto, deve rever o que foi acordado e obtenha o compromisso de ambas as partes que continuarão também a procurar uma resolução para o conflito e cumpra o plano acordado com eles para prosseguirem o trabalho.
Recomendo que deve acompanhar ambos individualmente e verificar em conjunto como correm as coisas nas próximas semanas ou meses. Forneça-lhes os apoios que necessitam para continuarem na direcção certa que é a da melhoria da sua relação de trabalho.

Como ser um bom Gestor de Projecto

Manter uma equipa de projecto a trabalhar com ritmo e consistência pode ser um desafio, especialmente quando os orçamentos são curtos e as expectativas são altas. Os gestores necessitam de definir a melhor forma de liderar e motivar, mas uns princípios base podem manter a orientação para o caminho certo.~

Conheça a sua função

Enquanto líder do grupo, a sua preocupação principal deve ser com o próprio grupo. Mesmo se é um gestor que mete as mãos na massa, lembre-se que está ali também para treinar, avaliar e orientar. Arranje tempo regularmente para cada uma destas áreas

Compreenda o valor dos seus colaboradores

Não consegue alcançar só por si os objectivos da sua equipa, assim trabalhe para ajudar os seus colaboradores a fazer as suas tarefas. Remova obstáculos, esforce-se nos conflitos e lute pelos recursos que os seus colaboradores necessitam para alcançar o sucesso.

Seja justo

Evite brincar aos favoritos ou colocar as suas próprias ambições acimas das da equipa, porque as pessoas são rápidas a decifrar as palavras e as acções que são injustas ou de autopromoção. Terá de continuar a tomar decisões impopulares de vez em quando, mas desta forma garante o respeito da sua equipa.

Trate os seus colaboradores como adultos

Há poucas coisas que minam tanto o respeito e o entusiasmo como ser criticado, disciplinado ou embaraçado em público. Seja suficientemente cortês com os seus colaboradores para ter as discussões sensíveis em privado, dê-lhes sempre o benefício da dúvida quando ocorrem erros e nunca perca de vista os seus objectivos de carreira individuais.

Procure as Forças de cada membro da equipa e aproveite-as

Pela utilização das forças naturais dos seus colaboradores até ao seu potencial pleno, estaremos não só a permitir que o colaborador sinta um tremendo sentido de valor e de realização, como a equipa estará a beneficiar destas competências.

Encoraje o sucesso

Quando um colaborador consegue realizar uma meta difícil ou alcança uma vitória, devemos aproveitar. Informe o resto da equipa acerca da realização, procure formas de repetir o sucesso em projectos futuros e mantenha-se atento às oportunidades que permitirão a este colaborador ajudar e apoiar outros para alcançarem resultados similares.

Forneça Respostas, rápidas, directas e úteis

Sem estas respostas os seus colaboradores ficarão frustrados por que os seus esforços não estão a dar resultados e você exasperar-se-á porque a sua equipa não está a atingir o seu potencial.

Foque-se no sucesso de longo prazo

Não espere que os colaboradores, de um dia para o outro, aprendam novas competências, modifiquem comportamentos ou melhoram a sua performance. Em vez disso, trabalhe em pequenas mudanças aqui e acolá e, desta forma, suscitará sólidos resultados de longo prazo.

Use os enganos como ferramenta de aprendizagem

Após ter trabalhado coma equipa para corrigir um erro, altere o seu foco e tente ajuda-los a compreender como ocorreu o engano, quais os sinais que não foram entendidos e como eles podem evitar repetir mais tarde o mesmo erro.

Esteja consciente que não é perito em tudo

Se tiver na equipa um colaborador com maior conhecimento numa área particular, não tente esconder ou reduzir isso-, antes celebre isso. As equipas de sucesso combinam os talentos específicos de cada elemento num conjunto com alta performance, quaisquer inseguranças ou egos que ponha na mesa só irão minar esse conjunto de alto potencial.

Delegue e depois saia do caminho

Ao afastar-se e permitir aos seus empregados fazer os seus trabalhos irá instilar neles uma grande confiança ed um alto grau de responsabilidade. Estará, ainda a apoiar os esforços deles para incrementar as suas competências e melhorar as suas capacidades de tomada de decisão.

Seja o chefe do clube de fãs

Você deve ser o maior fã e apoiante dos seus colaboradores. Garanta que a gestão de topo esteja consciente das realizações do seu grupo, trabalhe com os membros seniores para obter o devido reconhecimento pelos sucessos da equipa e seja diligente a recompensar as realizações individuais, se for apropriado, com promoções.

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!

Quer saber como falhar nos seus projectos

Vamos rever como podemos fazer tudo errado dum ponto de vista de gestão de projecto. Isto parece o contrário de tudo aquilo que procuramos nestas páginas, mas é também uma forma de passar o que NÃO deve ser feito num projecto. É pena que isto seja, também, um espelho da corrente realidade. Espero que esta experiência ajude!
Para conseguir entregar os resultados do projecto ACIMA do orçamento e ACIMA do tempo previsto, tornando miserável o cliente pelo caminho, então…

Nunca Planeie

“Para quê planear se ninguém segue os  planos? Eu imprimo os planos, mas eles são esquecidos e colocados na prateleira. O que eu devo fazer é arregaçar as mangas e envolver-me no trabalho do projecto!”
Um homem sensato disse que “Se falhar a planear, então planeias falhar”. O planeamento é acerca de nos assegurarmos de ter as pessoas certas nas actividades certas, na altura certa. Só se planearmos podemos estar certos que iremos realizar o projecto dentro do tempo proposto.

Não comunique

“Mas porque é que eu tenho de dizer a toda a gente e sempre o que está a acontecer? Não tem sentido. O que eles têm de saber é qual é a lista de tarefas diárias. A comunicação faz perder muito tempo. Não vale a pena!”
A razão para comunicar é que isso mantém todos a ver a mesma página para que todos saibam como todos os outros estão a trabalhar, quando é difícil e quando não é. Por exemplo, se ninguém sabe que o projecto está a atrasar, então qual é a possibilidade de conseguir realizar em tempo se não comunicamos?

Esqueça a liderança, está sobrevalorizada

“A minha equipa tem é de fazer o seu trabalho senão levam uma corrida quando eu chegar ao escritório amanhã. Temos de estar sempre a mostrar o chicote para garantir que o pessoal trabalha efectivamente.”
Muito embora esta abordagem até possa funcionar no curto prazo, as pessoas precisam de ser recompensadas e reconhecidos os seus esforços no longo prazo, para estarem motivados. Em breve, precisam de sentir valorizadas e só um verdadeiro líder pode fazer isso. Precisamos se ser sempre positivos com a equipa, mesmo quando precisam de um resmungo. Seja equilibrado. Seja construtivo. Ponha-se nos seus sapatos, As grandes equipas têm grandes líderes, É tão simples como isto.

Apaixone-se pelo deslizar dos objectivos

“Para quê estar preocupado se o cliente pediu mais mudanças. Se o projecto está atrasado não é por nossa culpa. Se querem estar constantemente a alterar o âmbito do projecto, não sou que os vou parar”
Certo, o seu cliente pode mudar quando quer, mas você tem de ter controlo sobre isso porque quando o prazo foi excedido e o projecto está longe de estar completo devido a todos os pedidos de mudança que permitiu, posso assegurar que o cliente não vai ficar satisfeito.

Esqueça o cliente logo que começar o projecto

“Logo que obtiver a aprovação do cliente, não preciso de falar com ele até à conclusão do projecto. Quanto menos o envolver no projecto, menos coisas ele pode estragar. Se eu não falar com ele, então garanto que ele não me perturba.”
Esta abordagem pode funcionar até que seja necessário o apoio do cliente. Então estamos em trabalhos! Se precisa que o cliente aprove mais tempo, dinheiro ou recursos, tem de o manter ao seu lado durante todo o tempo. O cliente tem de ser informado a cada passo do progresso e sentir que é parte da equipa de projecto, se pretender o seu apoio total.
Trate o cliente como se este fosse o seu melhor amigo. Mantenha-se do seu lado e peça favores quando achar que deles necessita. Se tiver o seu apoio total, então receberá o que precisa quando pedir.
Este exercício ao contrário pretende que assim se compreenda o que não se deve fazer para garantir o sucesso.

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.

Revitalizar o Projecto

O projecto em que está envolvido não está a correr bem? Pensa que necessita de um novo arranque, com a injecção de energia nova e motivação, desta forma incrementando as possibilidades de sucesso?

A maioria dos gestores de projecto fica cansada em algum ponto do projecto. Apesar de tudo, gerir pessoas, dinheiro e tempo é cansativo. Mas se não se conseguir manter com domínio das regras do jogo durante todo o tempo de projecto, então também a equipa pode ficar stressada e os limites de tempo podem começar a deslizar. Há, no entanto, algumas medidas ou cuidados que permitem arrancar de novo com o projecto, rejuvenescê-lo e desta forma tentar dar-lhe um novo alento de vida.

Pare e reanalise

Os projectos estão sempre avançados numas áreas e atrasados noutras. Pare e avalie de forma firme o progresso do projecto até à data. Faça uma lista de todas as áreas em que se encontra em atraso. Depois, estabeleça prioridades na lista e calcule a quantidade de esforço que irá necessitar para recuperar o atraso e voltar ao ritmo certo. Será que existem actividades que possam ser concluídas por outros externos à equipa? Se existem actividades não críticas que possa realizar em empreitada externa, então é agora a altura para o considerar. Utilize todos os recursos que consigamos atribuir para completar as actividades atrasadas o mais cedo possível

Verifique os planos

Logo que consiga recuperar, revisite o seu Plano do Projecto. Actualize todas as actividades do plano e avalie o seu agendamento de avanço. Necessita revitalizar a sua equipa e para fazer isso, precisa de ter um plano retrabalhado que mostre como irá realizar o resto do projecto em tempo. Só isso poderá aumentar a motivação e o entusiasmo para a conclusão de um plano revitalizado. Muito especialmente se a equipa consegue perceber que este é atingível.

O caminho à frente

Tem agora um plano que voltou a ser claro para todos e que permite ver o caminho a seguir, tem de colocar a equipa na sua realização. Organize um almoço com a equipa. Apresente-lhes de forma sequencial os desafios remanescentes e a escala de tempo dentro da qual devem ser atingidos. Tente não referir o período anterior ou alguma das falhas até à data. Em vez disso, seja positivo e concentre-se no caminho em frente para obter o seu apoio. Se possível, peça ao cliente para o acompanhar, para fixar a equipa naquilo que é necessário para concretizar e quando. Diga-lhes que está orgulhoso deles e que está certo das suas capacidades para alcançar o sucesso.

Individualização

O truque está em fazer com que cada pessoa sinta que é uma cunha indispensável na roda dentada. Reúna com eles individualmente e reconheça as suas realizações sempre que as vê.

Pequenas vitórias

Uma equipa vencedora gosta de saber que está a ganhar desde o início. Para obter esse estímulo, foque-se em realizar um par de actividades críticas mais cedo e, de seguida anime-os com o sucesso e com o momento ganhador em que se posicionam. Prepare-se para obter outras vitórias rápidas e volte a afirmar os sucessos. Este movimento cria um sentimento de realização e este vai construir uma nova motivação à equipa. Claro, que o projecto só estará concluído quando todos os produtos ou serviços forem entregues, mas assuma que metade do gozo está em caminhar para isso.

Existem outros meios de obter um resultado semelhante, mas considere que para melhorar a ligação da equipa ao projecto e ao seu sucesso, todos estes métodos devem ser usados com alguma planificação para garantir resultados.

Simples passos para criar o Plano do Projecto

O passo mais crítico do Ciclo de Vida de um projecto é a criação do seu Plano de Projecto. Muitas pessoas ao enfrentarem a necessidade de criarem o seu primeiro plano, bloqueiam e em vez de identificarem o que devem fazer para alcançar os objectivos, começam a fazer uma coisa de cada vez, conforme devem resolver o que se lhes coloca. Esta não é uma boa prática!

Podemos com algumas regras definir um processo simples e eficiente de criar o Plano, o que nos permitirá depois durante a sua execução medir a respectiva performance. Então, o que devemos fazer?

O Plano do Projecto identifica as actividades exigidas para a conclusão do projecto e atingir o seu objectivo, bem como as milestones, dependências, recursos e escalas de tempo envolvidos.

Para criar o Plano do Projecto precisa em primeiro lugar de definir uma Work Breakdown Structure ("WBS"). Esta identifica cada uma das fases, produtos e resultados que permitirão alcançar os resultados do projecto. Pode então especificar as actividades requeridas para a realização do trabalho do projecto. Irá de seguida identificar os recursos requeridos para cumprir cada actividade listada. Finalmente irá construir um agendamento do projecto que descreverá o fluxo de actividades e a duração envolvida na conclusão de cada uma destas conforme especificado.

Os passos são então os seguintes com um pouco mais de detalhe:

Definir a Work Breakdown Structure

Este é o primeiro passo para a criação de um Plano de talhado do seu projecto – o desenvolvimento de uma detalhada e compreensiva Work Breakdown Structure (WBS). Esta ferramenta permitirá listar as fases, os resultados, e as actividades gerais requeridas para completar com sucesso o projecto. Descreva a ordem por que as actividades serão realizadas e identifique quaisquer dependências chave, internas ou externas. Faça ainda a identificação das milestones críticas do projecto, tais como a conclusão de resultados chave do projecto.

Identifique os recursos requeridos

Tendo concluído a inventariação das actividades requeridas para realizar o projecto, necessita agora de identificar os recursos genéricos requeridos para concluir cada actividade. Exemplos de tipos de recursos incluem: trabalhadores a tempo inteiro e em part-time, contratados, equipamentos e materiais. Para cada tipo de recurso identifique a quantidade necessária, as datas de execução e as actividades na WBS em que este recurso será utilizado para a ajudar na sua efectivação.

Construir o Agendamento do projecto

Recolheu desta forma toda a informação requerida para construir um agendamento detalhado do projecto. Para o construir irá necessitar de:

• Listar todas as fases e actividades que incluímos na WBS
• Sequenciar as fases e actividades
• Adicionar as dependências internas e externas
• Definir as durações adequadas
• Adicionar alguma contingência adicional para mitigar o risco
• Atribuir os recursos requeridos para executar as actividades
• Identificar e incluir as milestones críticas de realização
• Especificas quaisquer assunções e constrangimentos

Aqui está um processo simples de identificar o seu Plano de Projecto. Utilize-o e sirva-se dele para prever a realização e para medir as diferenças de execução que se irão apresentar durante a realização.

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.

Gerir o esforço de transformação

O esforço de transformação foi então financiado e a equipa segue a liderança após um primeiro empenho na transformação. Todos conhecem as áreas a mudar, mas agora o papel do líder da transformação tem de evoluir.

Conforme o esforço é desenvolvido a liderança altera-se para uma função de Protecção, visto que o esforço de transformação estará, na sua fase inicial, numa situação frágil e, mesmo nas melhores organizações, haverá um pequeno exército de pessoas a tentar de forma consciente ou subconsciente miná-lo.

As pessoas têm medo da mudança. Se damos corpo à mudança e obtivemos financiamento para ela e fizemos uma demonstração pública disso, as pessoas começam a receber uma mensagem de que a mudança está a chegar. Isto pode criar ansiedade e incerteza e levar a que alguns dos membros da sua equipa tomem decisões irracionais. Tem de proteger o esforço de transformação e dar-lhe tempo para ter sucesso.

Há duas coisas críticas que deve fazer para proteger o esforço:

• Respeite as Decisões da sua Equipa de Projecto: Uma forma de minar o esforço de transformação é colocar em questão as decisões da equipa do programa. Embora ninguém deva ter receio de feedback construtivo, devemos resistir à tentação de substituir as equipas do programa por razões de maior eficácia, por exemplo. Se alguém à sua volta levanta uma questão relacionada com o programa, dirija-o para a equipa do programa e a sua estrutura de direcção para solucionar a questão. Se puser em questão a autoridade da equipa do programa a mudança não irá surgir.

• Suporte o esforço da gestão do dia-a-dia: Muito mais do que ultrapassar as decisões, deve procurar utilizar todas as mudanças que surgem do programa e embebê-las nas suas práticas de gestão diárias. Será que o programa criou novas métricas? Então reveja-as como parte das suas reuniões de revisão operacional. Foram implementados novos critérios de mudança? Peça que as restantes mudanças feitas sigam os mesmos critérios.

O seu suporte continuado e visível ao esforço será crítico para o seu sucesso de longo prazo. Pode ser facilmente ficar cansado pelos esforços de gestão do dia-a-dia e ficar com a percepção que já fez tudo para suportar o esforço. Mas não. Exige-se que de forma consciente pense em que forma visível poderá dar ao esforço um maior peso de apoio todos os dias. Respeitar decisões, embeber os resultados no trabalho do dia-a-dia, aparecer nos eventos do programa, oferecer encorajamento pessoal aos membros da equipa – todas estas acções dar-lhes-ão suporte e protecção que eles necessitam para terem sucesso no esforço de mudança.

Posts anteriores:

• O Esforço de Transformação
• Mudar não é de borla

Mudar não é de borla

Uma das actividades tácticas mais importantes que deve ser realizada é financiar o esforço de transformação.

Claro que isto até parece óbvio, por que todos sabem que uma mudança custa recursos – humanos e financeiros -, mas o que necessitamos é muito mais do que dar ao programa o dinheiro que ele precisa. Financiar é um símbolo muito poderoso para aquilo que a Liderança das TI valoriza. Muitos programas de transformação tiveram uma morte dolorosa porque tornaram-se só esqueleto e nenhuma carne. Apesar de falarmos e  nos empolgarmo, quando chega a hora de andarmos para a frente, o financiamento não se materializa. Isto é como quando um papagaio deixa de ter vento e cai, o que envia à equipa é uma mensagem  de que a liderança não valoriza o esforço realizado tanto como dizia e que afinal não falava seriamente da mudança.

Temos de evitar esta sina pelo público e conhecido financiamento do esforço. Esta acção significa de facto duas coisas. Primeiro, que temos de ser realistas acerca do que irá ser necessário. Reconhecer que a maioria esmagadora da «despesa» vais ser o tempo dos vossos colaboradores internos. Mas com base nos objectivos de transformação, pode ser que necessite de alguma consultoria externa, o aumento de alguns recursos para libertar a equipa e, ainda algumas ferramentas.

Seja lá o que necessita, não seja tímido. Obtenha o financiamento. Se não quer fazer agora e falhar, então espere até que esteja pronto e seja garantido.

Lançar um esforço de transformação sem financiamento e pela declaração simbólico que isto representa é certamente uma receita para o fracasso.

Com o financiamento garantido, faça um farol dele.

Faça reuniões. Envie emails. Faça sms em broadcast. Envie, enfim, uma mensagem em alto som e clara de este esforço é uma das suas mais importantes e críticas prioridades. Assegure-se que toda a sua equipa sabe que financiou este esforço com a quantia adequada – e isso é muito importante. Não pode haver dúvidas e não podemos fracassar. Torne claro para todos que este esforço de mudança irá ser conseguido.

Contribuiu para reforçar a liderança da equipa e da transformação.

O Esforço de Transformação

A liderança é uma coisa que não existe em abundância na maioria das organizações de TI. Se está a ler isto, provavelmente, já faz parte dum grupo exclusivo de pessoas preocupadas com a liderança ou é mesmo um líder – porque só um líder procura constantemente novas formas de melhorar.

A liderança de um esforço de transformação exige todas as competências de liderança que tem e estas devem ser aplicadas com determinação para serem efectivas neste contexto. A razão para isso, em muitos casos, é porque a liderança é muito simplesmente acerca de visão e confiança. Estabelecemos a direcção e movemo-nos nesse sentido com confiança e a equipa segue-nos. Embora isto seja um ponto crítico do que é necessário realizar, um esforço de transformação numa organização é tanto acerca de construir líderes como acerca de liderança.

Para realizar um esforço de transformação com sucesso são necessárias várias coisas. Hoje falamos de como nos tornarmos um Campeão da Mudança.

A primeira coisa e também a mais importante para nos tornarmos num líder das transformação é sermos o corpo e a alma da mudança. Uma das maiores barreiras da mudança é a simples inércia.

A estrada da modernização das estruturas de TI está juncada dos esforços abandonados de esforços falhados de mudança. Não podemos culpar ninguém, mesmo na nossa equipa, por acreditarem em que a verdadeira mudança nunca ocorre.

Precisamos de mudar isto.

Seleccione algo pequeno, mas significativo, que exige que mude a forma como opera e mude-o – de forma pública. Pode ser, por exemplo, que quer ser chamado sempre que se declare um Incidente de Maior Dimensão – qualquer que seja o dia ou a hora. Talvez possa ser que agora irá pessoalmente aprovar qualquer Mudança importante ou que irá pessoalmente dirigir a Reunião de Revisão de Incidentes de Maior Dimensão e que irão concentrar-se nas falhas dos processos e não nos esforços heróicos. Qualquer que seja, deve:

• Afectá-lo pessoalmente e exigir que deve de forma óbvia e visível alterar o comportamento
• Exigir um investimento pessoal da sua parte – não pode ser simples e conveniente
• Ser significativo – não pode ser só para fazer figura.

Inicia-se aqui um processo de construção apoiada da confiança na mudança.

Mas ainda é necessário muito!

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

Nada substitui saber do que se está a falar!

As organizações que tiveram sucesso na implementação de processos ITIL são aquelas que conseguiram perceber que para cada problema complexo existe uma solução simples e atractiva que está errada, ou como no caso da ITIL – incompleta.

Textos anteriores sobre o assunto:

• A ITIL só por si não resolve!
• Deixe de Procurar uma receita

Tem tudo a ver com seguir ou liderar!

A liderança exige que o líder tenha uma compreensão «operativa» sobre a ITIL. Tal não significa uma «introdução à ITIL» de duas horas apertada entre outros assuntos importantes, Muitas vezes a gestão executiva das TI pede que a empresa comprometa recursos significativos em ferramentas, consultoria e formação para “fazer ITIL” sem ter sequer uma luz do que é que esta trata. Isto é sintomático da “concepção simplista” de que falamos. “Parece simples demais para ser verdade. Assim «faça ITIL» e depois faça outras coisas mais importantes como, por exemplo, perceber por que é que parece que todos andamos a apagar fogos e porque é que os meus colegas continuam a enviar-me brochuras acerca de companhias de outsourcing.”

Qualquer pensamento acerca de uma estrutura, metodologia ou standard deve ser empreendido com a compreensão completa dos objectivos e uma descrição sem ambiguidades do resultado desejado.

Vá comprar alguns livros; sim e leia-os também. Junte-se a um grupo local da internet. Faça a sua própria pesquisa, faça um curso e obtenha uma certificação. Perceba o que é a Gestão do Serviço e como é que ele também não é importante.

Compreenda o seu apetite pelo risco!

Isto não é acerca de «para a frente é que é o caminho». Isto é acerca de criar uma boa compreensão de quanto risco estão as TI e o negócio dispostos a aceitar. Em palavras simples, você está a gerir o risco; a compreender o que são os riscos, assegurar-se que os riscos são transparentes para os stakeholders e a tomar as decisões necessárias para aceitar, mitigar ou transferir o risco. Esta é a razão de a V3 da ITIL pôr um grande foco na governação.

Isto significa que todos os que têm uma palavra no resultado da implementação de qualquer estrutura, método ou standard compreendem quais sãos os riscos/recompensas, como podem enfrentá-los e como podem ser transferidos para outros, tais como fornecedores ou parceiros. A importância desta compreensão do apetite pelo risco fica mais clara de seguida.

Exige-se alguma integração!

Exige-se liderança para oferecer visão e direcção, muito mais do que uma compreensão «literária» do assunto e, entenda, que implementar uma mudança organizacional é um trabalho arriscado.

Não existe «um modelo para todas as situações» na Gestão dos Serviços de TI, apesar daquilo que os vendedores de software, consultores e formadores possam ter afirmado. A Gestão dos Serviços de TI é um problema complexo e a sua solução exige muitos componentes móveis. Embora a ITIL possa não ser a resposta, certamente será uma parte da resposta. Faltam-lhe alguns dos componentes como Governação das TI, gestão de recursos, gestão da qualidade e da segurança. Assim «fazer a ITIL» não é tanto em fazer a ITIL, mas a integração de um conjunto de estruturas, métodos e standards que quando combinados oferecem algumas das soluções para a Gestão dos Serviços de TI.

Sumário em jeito de conclusão

A gestão dos Serviços de TI é uma realização complexa. O ambiente em que a empresa de hoje compete é muito complexo e as organizações de TI dos nossos dias são requeridas a fornecerem serviços de TI que permitam que a empresa concorra com sucesso no mercado.

As organizações que tiveram sucesso na implementação de processos ITIL são aquelas que conseguiram perceber que para cada problema complexo existe uma solução simples e atractiva que está errada, ou como no caso da ITIL – incompleta. Eles compreenderam que não existe uma solução rápida e fácil. Eles sabem que a ITIL não pode ser “comprada” e que não podem simplesmente «fazer ITIL» para sua organização. Eles aprenderam que devem ser “eles a fazer “ de forma a internalizarem a mudança organizacional requerida para o sucesso com a ITIL.

E eles sabem, também, que quando isso acontece, não há um limite natural para o nível de sucesso que pode ser alcançado por uma organização de TI ou uma empresa.

Textos anteriores sobre o assunto:

• A ITIL só por si não resolve!
• Deixe de Procurar uma receita

Planear Projectos: os grupos de processos

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

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

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

Estabeleça uma Direcção

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

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

Selecção das Actividades

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

Interligação

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

Atribuição de recursos

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

Baseline, Dados Reais e Reporting

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

Deixe de procurar uma «receita»

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

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

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

Siga ou lidere, mas saia do caminho!

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

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

Melhorar o conhecimento sobre projecto

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

1. Seja sério

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

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

2. Alargue o seu horizonte

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

3. Tire apontamentos

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

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

4. Seja específico

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

5. Recompense os seus esforços

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

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