Controlar os pedidos de Alteração nos projectos

Os pedidos de alteração quando um projecto se inicia são uma parte inevitável do projecto. Elas podem ser o resultado de mudanças externas no negócio ou podem ser mudanças internas requeridas porque os propósitos originais do projecto não foram claramente definidos ou compreendidos.

As mudanças requeridas por factores externos estão normalmente fora do controlo de um gestor de projecto e há muitas vezes poucas escolhas para as enfrentar. Muitos dos gestores de projecto experimentados terão já colocado em posição um processo no início do projecto para tratar destes pedidos e o plano será suficientemente flexível para tratar delas sem afectar o resultado final.

Mas os pedidos de alteração provenientes de factores internos devem ser tratados de forma muito diferente. Num projecto ideal muitos destes devem ser evitados garantindo que os objectivos do projecto estão bem definidos, que os requisitos estão documentados claramente, que foram comunicados a todos os stakeholders e que estes compreenderam o que é esperado do produto final. Claro que nós não vivemos num mundo ideal e por mais profunda e bem detalhada que sejam as fases iniciais do projecto tem de existir em posição um efectivo processo de controlo da mudança.

Nem todos os stakeholders e utilizadores conseguem visualizar o produto final pela leitura da documentação e estudo de diagramas. Mesmo quando são usados protótipos para melhorar a produção de requisitos, estes são, pela sua própria natureza, produtos não inteiramente funcionais e serão inevitáveis incompreensões e assumpções nos projectos complexos.

De qualquer forma, a boa documentação e documentação clara dos objectivos e requisitos de projecto irão minimizar o número de pedidos de alteração.

Então qual é a melhor forma de controlar os pedidos de alterações num projecto e continuar a realizar a conclusão do projecto dentro de um orçamento, de escalas de tempo e âmbito?

Distinguir entre o Necessário e o «Era bom ter»

Cada um dos pedidos de alteração deve ter uma justificação (que tal um «business case») que os suporte, tal como o projecto tem uma justificação. Claro, que esta justificação pode ser muito simples e breve, mas é um elemento necessário de todos os pedidos de alteração antes que possam ser considerados para inclusão no projecto.
O elemento mais importante deste «business case» do pedido de alteração é o benefício esperado o qual deverá indicar o valor que será adicionado ao projecto pela mudança. Isto indicará, por si próprio, quais as mudanças que serão provavelmente necessárias. É importante reconhecer que a descrição de alguns destes «business cases» pode não beneficiar necessariamente o projecto em termos de tempo e orçamento, mas sejam necessárias para que o cliente se mantenha competitivo no mercado.
Se os benefícios não forem especificamente declarados então deve discutir-se a questão com a pessoa que requereu a alteração para determinar se existe um genuíno benefício de negócio.
Soluções melhor desenhadas, ou mais bonitas, com funcionalidades e mais atractivas não são benefícios, a não ser que possam ser apoiadas pela forma como estas tiveram um impacto positivo no orçamento e no plano do projecto, ou, um impacto positivo nos esforços dos utilizadores em completarem actividades regulares. As perguntas mais vulgares a que deve responder o «business case» são:

• · Qual é a mudança externa no negócio de que resultou este pedido de alteração?
• · Quais os factores internos de que resultou este pedido de alteração?
• · Como é que esta mudança irá afectar o tempo que levamos a completar o projecto?
• · Como irá esta mudança afectar o produto final para o utilizador?
• · Que poupanças serão realizadas pela implementação desta mudança?

Evite desperdiçar Tempo e Esforço

A forma mais óbvia de evitar desperdiçar recursos valiosos de projecto em pedidos de alteração excessivos e em todo o processo de gestão da mudança, é garantir que o projecto se inicia com objectivos e requisitos claramente definidos. É também importante o critério que iremos usar para determinar o sucesso do projecto estar documentado sucintamente desde o início do projecto. Deve garantir que estes documentos são distribuídos aos stakeholders e utilizadores e que estão acessíveis cópias dos documentos.

Planeie actividades incluídas no plano do projecto para tratar dos pedidos de alterações e se este tempo foi ocupado adie os pedidos importantes para a próxima semana. Garanta que todas as partes interessadas sabem como trabalha este processo.

Tenha um Critério Claro de Aceitação e Rejeição

Defina um critério para avaliar estes pedidos que não serão, ou não poderão ser implementados. Quem faz o pedido tem de compreender o critério e este tem de ser consequente. O critério essencial, como já vimos, é ter uma justificação escrita, um «business case», que esclareça os benefícios. Se não tiver pode ser de imediato devolvido a quem emitiu o pedido. Não perca tempo atrás de quem fez o pedido para saber qual é a justificação escrita. A responsabilidade disso é de quem faz o pedido que o deve fazer logo desde o início (mesmo que depois devamos discutir e aprofundar a discussão sobre esta justificação).

Esteja preparado para fundamentar as razões para rejeitar um pedido de alteração com uma descrição bem pensada do porquê para não incluir a mudança. Mantenha-se na sua decisão a não ser que o sponsor do projecto queira aumentar o orçamento ou o tempo disponível no projecto.

Esteja, também, preparado para ser flexível e para negociar a substituição de uma actividade em favor da mudança quando não há nem orçamento nem tempo disponível.
Aplique sempre as melhores práticas de gestão de projecto em todas as áreas do projecto se quer aumentar as suas oportunidades de sucesso.

A Mudança e Liderança

A liderança é uma coisa que não existe em abundância na maioria das organizações. 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. Este texto corresponde a uma reflexão que usualmente comunico em formação.

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 da transformação é sermos o corpo e a alma da mudança. Uma das maiores barreiras da mudança é a inércia simples.

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

Precisamos de mudar isto

Selecione algo pequeno, mas significativo, em 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:

·         Afetá-lo pessoalmente e exigir que force de forma óbvia e visível uma alteração de comportamento

·         Exigir um investimento pessoal da sua parte – não pode ser simples e conveniente

·         Ser significativo – não pode ser só de fazer figura.

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

Mas ainda é necessário muito!

O propósito é enviar uma mensagem de força à sua equipa de que a mudança está realmente a chegar – e que está a começar consigo. Diga-o, sempre que tem uma oportunidade, e faça por que a sua equipa compreenda como está empenhado de forma séria neste esforço.

Financiar e Mostrar

Uma das actividades tácticas mais importante 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 valoriza. Muitos programas de transformação tiveram uma morte dolorosa porque tornaram-se só esqueleto sem nenhuma carne. Apesar de falarmos e empolgarmo-nos, 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 uma mensagem à equipa 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 a sina triste do público 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 e bom som e clara que este esforço é uma das suas mais importantes e críticas prioridades. Assegure-se que toda a 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.

Proteger e Gerir

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

Deixe-os falhar (mais ou menos!)

A última coisa que deve fazer para liderar efetivamente um esforço de transformação é o mais simples e mais difícil - você deve deixar a equipa passar pelo ciclo de tentativa e erro. E isso significa que algumas das coisas que eles fazem falharão.

A transformação organizacional pode ser confusa. Não segue um plano de projeto simples. Como um dos principais objetivos é criar uma nova geração de líderes na organização, deve capacitá-los para liderar esse esforço e dar-lhes a latitude necessária para executá-lo. Devem ter permissão para experimentar e assumir riscos sem medo de recriminação. Isso significa que deve romper o véu corporativo da infalibilidade e celebrar a transformação da organização quando ela for bem-sucedida e quando falhar - desde que a falha seja usada como uma oportunidade para continuar e melhorar a organização.

Embora isso possa ser muito difícil, muitas vezes é durante os esforços fracassados que a equipa aprende mais sobre como realmente mudar a organização. E isso leva a resultados explosivos e exponenciais. Deve sempre reagir severamente ao fracasso causado por esforços desinteressados ou manobras políticas, mas o fracasso resultante da tomada de risco e uma tentativa séria de melhorar a organização deve ser aceite e até celebrado por que isso permitirá que a organização continue amadurecendo.

Construir a Geração de Líderes

Ao adotar estas quatro características e se tornar um verdadeiro líder de transformação, será capaz de alcançar resultados significativos para a organização. Talvez o impacto mais duradouro desta abordagem, no entanto, seja o legado de liderança que deixará para trás.

O tipo de apoio que isso requer tem o efeito de criar confiança nas equipas. Os seus colaboradores verão que a verdadeira mudança pode ocorrer e encontrarão em si mesmos traços de caráter que eles podem não ter conhecido. Eles tornar-se-ão mais ousados na paixão para tornar a organização melhor. Eles sentir-se-ão empoderados de que podem fazer a diferença. E sentir-se-ão investidos de que não são meramente uma engrenagem nas obras, mas um participante ativo na definição do futuro da organização. Eles tornar-se-ão uma geração de líderes que lhe permitirá acelerar os esforços e obter resultados de negócios impactantes nos anos vindouros.

Luís Quintino

KPIs de Performance de Projecto

Quais são as mais críticas métricas de performance de projecto ? Com base no plano do projeto podemos identificar uma lista das mais importantes:

• Planeamento – planeado versus real – preferencialmente através do Valor Ganho

• Funcional – % desenhado, implementado, testado, produzido

• Realização em tempo – milestones planeadas versus as milestones reais

• Custo

• Custo planeado versus custo real

• Total Planeado na Conclusão versus Revisto ou estimado na Conclusão

• Crítico e outros defeitos – Planeado versus Real + tendência

• Recursos (Pessoas, Equipamentos)

• Recursos Planeados versus Recursos Reais

• Recursos Totais Planeado na Conclusão versus Revistos ou estimados na Conclusão

• Riscos – Novos, Fechados, Abertos + Tendências

• Questões – Novas, Fechadas, Abertas + Tendências

• Resultados – Planeados versus reias até à data

A standardização dos valores a reportar ajuda a mantermo-nos no caminho certo.
Naturalmente que todas estas métricas são quantificáveis. A informação qualitativa pode ser útil quando preparado no seguimento das métricas acima. Os problemas só começam quando as pessoas começam a esgrimir as suas declarações qualitativas e esquecem-se de colocar no relatório algumas das métricas quantitativas. ~

Luís Quintino

«Almofadas» de tempo no Plano

No mundo da gestão do projeto, as coisas correm mal! Esta é uma característica inerente aos planos, nunca correm conforme planeados. É por isso que bons gestores de projeto irão registar e acompanhar os riscos associados às atividades do projeto. Ainda assim, é difícil encontrar todos os riscos que podem estar escondidos dentro do cronograma do projeto. Por isso que alguns gestores de projeto adotam a prática de adicionar um ‘buffer’ de tempo na programação.

Sim. Tal como uma reserva de gestão ou reserva de contingência está incluída num orçamento como um item de linha, os gestores de projeto podem incluir uma «almofada» (‘buffer’) de tempo como um item de linha na programação. Então estes ‘buffers’ de tempo são uma forma geralmente aceite para explicar questões desconhecidas no cronograma. Se não usar esta «almofada» de tempo como item de linha o mais provável é que, involuntariamente, esconda estes ‘buffers’ de tempo dentro do plano de qualquer maneira.

Vamos discutir estas «almofadas» de tempo nos planos e a prática de as tornar visíveis. Temos de compreender que a sua utilização é outra ferramenta daquelas a que os gestores de projeto podem recorrer.

Deve ou não estar escondida?

A primeira questão é se esta «almofada» deve ser escondida ou deve estar visível. Para projetos de tempo e materiais, de forma definitiva, não faz qualquer sentido esconder este ‘buffer’ já que está garantido o pagamento de todo o tempo gasto no projeto. Mas para contratos de preço fixo, em que nos comprometemos a um custo fixo do projeto e uma data estabelecida de entrega, a existência de um ‘buffer’ escondido pode ser adequada. Geralmente num contrato de preço fixo não se mostra a margem de lucro e isto é uma prática standard aceitável. Da mesma forma pode ser aceitável não mostrar a margem de tempo para a data de fim do projeto.

Se não é utilizado um ‘buffer’ de tempo visível, como descrevemos, então o mais provável é estarmos a esconder ‘buffers’ não declarados. Por exemplo, podemos estra a exagerar o tempo e o custo de atividades individuais. Isto é conhecido como «engordar» as atividades. ‘Engordar’ é a adição de tempo e / ou custo a uma atividade para fornecer uma estimativa conservadora do tempo de atividade e / ou de metas de custo. Assim, «engordar» as atividades é uma das principais formas de ‘buffer’ escondido dentro de um cronograma.

Atitude perante o projeto

Outro processo é ser pessimista. Quando são fornecidas estimativas de duração de três pontos (otimista, mais provável, pessimista), usa-se os valores mais pessimistas para produzir um plano conservador. Mais uma vez, esta é uma forma de ‘buffer’ de tempo escondido. Outros processos, incluem, ignorar as curvas de aprendizagem ou a introdução de ‘ramp-up’ ou fatores de mobilização.

Embora, possa ser legítimo esconder ‘buffer’ num contrato de preço fixo, é recomendável que sempre torne os seus ‘buffers’ visíveis. É prática geralmente aceite que os gestores de projeto podem possuir ‘buffers’ de tempo para ajudar a ajustar para imprevistos.

Mais uma vez, a reserva de gestão de orçamento é uma prática amplamente aceite.

Mudar a atitude dos ‘donos de obra’

Nem sequer é grande extrapolação a partir daqui incluir também contingências orçamentais de tempo. Os ‘buffers’ de tempo visíveis também promovem a transparência e abertura num projeto entre o gestor de projeto e outras partes interessadas. O uso de ‘buffers’ visíveis também incentiva os membros da equipe do projeto a serem abertos e honestos sobre seus próprios ‘buffers’ de tempo.

O objetivo deve ser otimizar a programação para alcançar os objetivos de custo e tempo de uma forma atempada e eficiente. Depois, pode concentrar-se numa margem de segurança, no final da cadeia de projeto e utilizar apenas quando o risco se materializa.