Maneiras de realizar os benefícios do projeto

O objetivo de completar projetos nas empresas, quer em tecnologia, sistemas, software ou mudança organizacional, é obter o benefício da mudança que é entregue. Os projetos são feitos para melhorar as coisas, por isso é importante saber quais os benefícios que você pode esperar de um projeto e como estes serão medidos.

Infelizmente, muitos projetos não possuem planos robustos de realização de benefícios e, quando o trabalho é concluído, ninguém sabe se o projeto realmente alcançou o que ele pretendia entregar. Isso é particularmente comum em projetos que não fazem parte de um programa, pois as estruturas de gestão de programas tendem a ser mais fortes na realização de benefícios do que as metodologias de gestão de projetos.

Aqui estão três dicas para ajudar a construir uma cultura de benefícios fortes para o seu PMO.

1.      Clarifique o que é um Benefício

Todos sabemos o que é um benefício, certo? Na realidade, todos na Direção do Projeto provavelmente têm uma ideia diferente sobre os benefícios que o projeto irá entregar. As agendas pessoais entram em jogo, o que é de se esperar. As partes interessadas individuais procurarão o "o que está nele para mim" e, potencialmente, perderão os benefícios da imagem maior aqueles que serão entregues mais amplamente em toda a organização.

Trabalhe com as partes interessadas e o Conselho do Projeto para estabelecer quais os elementos da estratégia corporativa que este projeto ajudará a alcançar. Deve ser capaz de alinhar claramente os benefícios do projeto com metas mensuráveis que contribuam para objetivos a nível corporativo.

Pode também incluir benefícios que só têm impacto num departamento ou que estão nas agendas pessoais dos executivos, mas estes devem ser complementares ao entendimento comum sobre os benefícios gerais do projeto.

2.      Nomeie os proprietários dos benefícios

Os benefícios como as atividades precisam de proprietários. Se não nomear proprietários dos benefícios, estes não serão medidos e podem nem ser realizados de todo. O proprietário do benefício é, usualmente, a pessoa que o recebe, assim se o benefício é um aumento de vendas, será então o Diretor de Vendas a pessoa responsável por gerir a realização deste benefício.

Nomeie os proprietários de benefícios o mais cedo possível, de preferência logo após o acordo de projeto ter sido aprovado. Essas pessoas podem colocar a realização e mensuração dos benefícios incluídos em seus objetivos anuais e nos das suas equipas.

Não basta simplesmente nomear os proprietários. Eles devem assumir toda a responsabilidade pelo benefício, o que significa que eles também precisam entender como será entregue através do projeto e como será medido.

3.      Defina um mecanismo de registo dos benefícios

Pode achar que o proprietário do benefício quer ser responsável por criar o mecanismo para registrar os benefícios. Alternativamente, podem querer ajuda do PMO. Algumas ferramentas de gestão de projetos corporativos têm a capacidade de registrar informações que serão úteis para o rastreamento de benefícios, para que possa usar o conjunto de ferramentas existente para capturar dados úteis ou gerar relatórios.

Idealmente, o PMO pode padronizar a maneira como os benefícios são rastreados e medidos, embora, como os benefícios variam tão de forma irregular, uma abordagem padrão pode não ser prática em todas as situações. Dito isto, é bom que o PMO tenha o quadro geral para que possam produzir relatórios consolidados para todos os benefícios em todos os projetos e programas.

Esteja ciente de que nos primeiros dias, o projeto pode entregar vitórias rápidas e você pode ver benefícios significativos que estão sendo alcançados. Após este primeiro ponto quente, os números podem se afastar. Os proprietários de benefícios devem estar preparados para que isso aconteça. Defina um período de tempo para o registo de benefícios. Pode achar que, após um ano, todos os benefícios foram absorvidos na previsão do negócio, como de costume, e não é mais necessário continuar a acompanhá-los.

O mecanismo de registo de benefícios também deve incluir uma maneira para o proprietário do benefício compartilhar os resultados com pessoas fora do PMO. O departamento também pode querer ouvir sobre os benefícios, especialmente se objetivos – e talvez os bônus – que dependem dos resultados.

Em suma

O acompanhamento de benefícios é muitas vezes considerado difícil, porque muitos casos de negócios são baseados em benefícios difíceis de medir ou intangíveis. Se esses números forem eliminados na preparação do caso de negócios, você terá benefícios estruturados e um plano para realizá-los. Então, todos os proprietários de benefícios o que precisam fazer é estabelecer como usar melhor os resultados do projeto para obter o maior benefício e registrar os resultados. Fácil!

A questão mais importante para projetos problemáticos

Não há sempre uma estrada fácil para os projetos. Independentemente de quão boas sejam as ferramentas de gestão e quão boa seja a equipa, às vezes os projetos acabam classificados no "Vermelho" ou "Em Problema". Isso pode acontecer por vários motivos, incluindo:

• O charter do projeto ou o seu ‘business case’ já não o suporta financeiramente devido a mudanças no custo de materiais, custos acrescidos ou simplesmente porque a oportunidade já não se apresenta.

• O sponsor deixa o projeto ou uma nova liderança de topo diminui o alcance ou altera a direção do projeto.

• Os recursos do projeto saem ou ficam indisponíveis por períodos de tempo, como por exemplo, por efeito de greves.

• O resto da organização mudou em volta do projeto e o que o projeto está a realizar deixou de ser adequado ao negócio.

O que pode fazer-se com um projeto com problemas

Os projetos problemáticos normalmente têm um status vermelho numa escala de saúde do projeto Vermelho-Amarelo-Verde. Isso pode ser porque o projeto excedeu o orçamento, está atrasado ou não entrega os produtos esperados para a qualidade desejada. Se reconhecer que seu projeto está preocupado, tem uma pergunta difícil de responder.

A tentação é replanear o projeto para entregar em tempo, ou cortar gastos para que possa recuperar alguns custos excedentes, ou colocar mais elementos no âmbito para entregar o que é necessário. Nenhum destes caminhos aborda a questão fundamental: "Dada a situação atual, vamos terminar este projeto?" Em outras palavras, há algum benefício a ser obtido de continuar, e se houver, como vai obter esse benefício?

Estabelecer o benefício

O gestor do projeto pode normalmente replanear, negociar o âmbito e gerir o orçamento. Contudo, o sponsor do projeto deve estar envolvido se o resultado da discussão acerca do caminho em frente num projeto com problemas possa ser fechar o projeto. Comece por realizar uma avaliação total ao estado do projeto hoje, com os dados da sua ferramenta empresarial de gestão de projeto e tudo aquilo que o possa ajudar a obter uma imagem clara da situação. Pode achar mais fácil perguntar a alguém – um colega ou um auditor independente do projeto – para fazer isto, já que a equipa do projeto pode estar demasiado próxima dos detalhes para ser capaz de realizar uma avaliação objetiva.

Quando tiver uma visão objetiva da situação do projeto, pode considerar o que vai acontecer seguidamente. Essencialmente, as opções são:

• Continuar até ao fim planeado do projeto, ignorando quaisquer sobrecustos ou atrasos até este ponto mas realizando uma gestão muita mais cuidadosa para a frente.
• Reduzir o âmbito do projeto e continuar por forma a que pelo menos qualquer coisa é realizada.
• Recupere o que puder do trabalho já realizado com a conclusão de qualquer elemento que deva ser terminado e depois feche o projeto.

Feche o projeto agora

O caminho que recomenda dependerá do que o projeto conseguiu alcançar at é ao momento e do trabalho exigido para recuperar de novo o seu controlo. Poderão haver alguns pacotes de trabalho que podem ser concluídos com um pequeno esforço extra e para benefício do espírito e moral da equipa, mais algum benefício para a organização, vale a pena realizar.

Se o projeto ainda tem algo significante para realizar, ou se está muito afastado de concluir algo ou obter algum benefício, pode ser melhor evitar mais perdas e fechar o projeto.

Induzir o sponsor a fechar o projeto

Depois da avaliação, terá uma ideia sólida sobre quais os próximos passos mais apropriados e, em muitos casos, isso significará fechar ou reduzir drasticamente o âmbito do projeto Pode ser difícil falar com o sponsor do projeto acerca do fecho do projeto. Podem haver políticas internas que podem significar isto não ser um movimento positivo para a sua carreira pois o sponsor vai ser identificado como tenho falhado. Podem dirigir a culpa diretamente para a equipa de projeto e o gestor de projeto pode aceitar ou discordar. Podem estar relutantes em desbaratar o dinheiro que já foi gasto.

Contudo, pode vir a ser uma discussão mais fácil do que pensa, especialmente se for muito claro que os esperados resultados do projeto já não podem ser alcançados. A avaliação objetiva do projeto torna-se uma ferramenta importante para convencer o sponsor do projeto do caminho em frente, mas a decisão será sempre dele.

Nem todos os projetos problemáticos têm de ser fechados, mas todos os projetos com problemas necessitam duma avaliação se devem ser fechados. Só compreendendo o que temos a ganhar com continuar poderá habilitar a decisão de continuar ou fechar.

Orientações para o uso de constrangimentos nos planos

O demasiado uso de constrangimentos no agendamento do projeto é desencorajado, entretanto quais são situações específicas em que os constrangimentos devem ser evitados e quais aquelas em que as restrições são adequadas?

Os constrangimentos descrevem datas importantes na vida do projeto que a lógica da rede sozinha não captura. Mas os constrangimentos, tanto rígidos como suaves, devem ser reduzidos no cronograma, porque as restrições impedem a propagação de atualizações de cronograma e / ou o progresso ao longo do cronograma, ou seja, as datas de restrição não mudam automaticamente e / ou atualizam quando o cronograma for atualizado.

Os projetos que têm muitos constrangimentos não são dinâmicos; eles geralmente requerem atualizações manuais tediosas para cada data de restrição. Portanto, o amplo uso de constrangimentos não é uma boa prática de programação, e há situações em que os constrangimentos são particularmente inadequados ou, com sorte, mais ou menos adaptados. Devemos considerar a adequação das restrições em cada situação.

Este post coloca orientações gerais sobre a adequação de inserir um constrangimento na sua situação particular do projeto.

Evite usar constrangimentos nas seguintes situações:

1.      Determinação da disponibilidade temporária dos recursos do projeto - A maioria dos agendamentos possuem calendários de recursos para especificar a disponibilidade de recursos do projeto. Os calendários de recursos são uma maneira mais dinâmica de definir disponibilidade sem restrições, corrigindo esforços relacionados com a atividade, conforme a disponibilidade da equipe de trabalho atribuída.

2.      Modelação de janelas de oportunidade - Fixar datas de tarefas com constrangimentos, novamente, é uma maneira estática de agendar datas da atividade. deve alterar manualmente essas datas de restrição.

Considere aplicar constrangimentos nas situações seguintes:

1. Dependências externas - as entregas são melhor modeladas usando uma combinação de milestone e constrangimento, ou seja, um marco limitado. A milestone marca o evento de entrega e o constrangimento especifica a data de entrega. Isso é melhor do que restringir uma tarefa sucessiva para começar não antes da data de entrega. Com o marco limitado, se a entrega for atrasada, você sabe que os atrasos no cronograma estão diretamente relacionados à entrega da matéria-prima e / ou do equipamento.
2. Reuniões - Atividades de grupo como reuniões exigem uma data acordada antes da programação. Restringindo a data da reunião para que ela permaneça fixa apesar do refluxo e fluxo das datas de início e fim das atividades circundantes.
3. Clima: o seu projeto de dragagem do rio deve concluir antes do aumento de caudal do rio no inverno, de modo a restringir a dragagem do rio para completar em ou antes, digamos, 22 de novembro. Um constrangimento, no entanto, pode não ser a melhor ferramenta. Os calendários de tarefa podem suportar melhor as janelas de oportunidade relacionadas ao clima para cada ano.
4. Eventos públicos - como reunir os participantes, o público precisa de uma notificação sobre quando o evento ocorrerá. A data planeada é divulgada e deve permanecer fixa.
5. Entregáveis - São datas contratuais que concordou em fornecer os produtos relacionados com o projeto.

Em suma

A maioria das orientações de agendamento desencorajam a ampla adaptação de constrangimentos. Algumas diretrizes exigem mesmo que as datas de restrição sejam especificadas no contrato.

Calendários de recursos e calendários de tarefas em lugar de constrangimentos suportam um cronograma mais dinâmico. A janelas de oportunidade é, portanto, melhor definida com as ferramentas do calendário de agendamento. Use milestones constrangidas para modelar a entrega de matérias-primas ou outros elementos do projeto,

Gestão de Risco

A gestão de risco é um dos grupos de processos essenciais na gestão de projeto e um daqueles que é realizado elementarmente e sem consistência, quando algo é feito. Na maioria dos projetos em que me vi envolvido a gestão de risco não era um processo do projeto e a sua análise só era realizada quando algum evento gravoso se apresentava. Mesmo nessas ocasiões a abordagem era a de principiantes.

Juntei aqui alguns dos posts que escrevi ao longo do tempo sobre a gestão de risco e tentei organizá-los para que a sua leitura os conduzisse por um processo de aprendizagem.

1. Iniciação do Projeto
2. Um princípio fundamental na gestão de Incerteza
3. Análise de Risco do Projecto: O que é e porquê fazer?
4. Tipos de Risco no Planeamento
5. Categorias de Riscos a ter em atenção
6. Principais Categorias de Riscos
7. Reporting de Risco em Projetos
8. O Risco, uma técnica simples

O último post apresenta uma técnica sumária para realizar uma simples análise de risco do seu projeto elencando os principais elementos que são origem de risco.

Porque é importante evitar Mudanças num Projeto – mas porque é que isso não pode ser evitado

As mudanças á Baseline Técnica de um projeto devem ser evitadaS tanto quanto possível, devido a duas razões:

• A primeira de todas, a mudança dos requisitos técnicos pode altera o custo relativamente ao que foi estimado a quando da propo.

• A segunda, as mudanças conduzem sempre a perturbações e retrabalho para todas as partes impactadas, muito mais complicado e difícil de avaliar do que custos diretos.

São implementadas numerosas mudanças durante a execução de um projeto. Algumas são parte da normal execução do projeto e não podem ser evitadas. Incluem o desenvolvimento do desenho, incorporação de in formação de fornecedores, et. Contudo, numerosas mudanças podem ser evitadas. Estas são pedidos feitos pelo Cliente que são realmente extras aos requisitos do Contrato.

Gerir as mudanças criadas pelo Cliente

Estas mudanças são de dois tipos:

• Mudanças reconhecidas. i.e., carta formal do Cliente com pedido de trabalho adicional, implementação de novo requisito, etc. solicitando ao Contractor que forneça uma estimativa do impacto de custo / agendamento, e
• Mudanças não reconhecidas que surgem na forma de comentários sobre entregas, requisitos transmitidos «ingenuamente» através de cartas, registos em atas de reuniões. Comunicação informal, oral, email, etc.)

Como enfrentar estas mudanças

Primeiro que tudo, o Contratante deve requerer do Cliente a receção de uma instrução oficial. A forma prática de o fazer é fornecer uma resposta standard para quaisquer destes pedidos, feitos, por exemplo, num comentário a uma Entrega do Contratante.

“Este comentário constitui um requisito adicional ao Contrato. (Explique o porquê referindo os documentos de contrato aplicáveis). Este pedido não será considerado a não ser que a Companhia emita um pedido oficial referente ao início de um pedido de mudança pelo cliente (referência do artigo do Contrato).

Isto irá eliminar a maioria destes pedidos, pois o Cliente evitará incorrer nos resultantes custos adicionais.

Se a mudança for reconhecida, iniciará o processo que conduzirá a uma compensação ao Empreiteiro.

Mantenha a posição em caso de mudanças não reconhecidas

Quando for recebido um pedido oficial do Cliente, poderá ser reconhecido que o pedido é uma mudança ao Contrato ou não.

Se a mudança é reconhecida, o Empreiteiro preparará uma estimativa de impacto de tempo / custo. Serão realizadas discussões com o Cliente acerca desta estimativa. O desafio para o Empreiteiro será chegar a acordo prontamente com o Cliente acerca desta estimativa, que será então registada formalmente num pedido de mudança: O Empreiteiro evita realizar a mudança, apesar das pressões, sem um Pedido de Mudança assi8nado.

Quando sabemos que nos projetos de grande dimensão toma pelo menos um ano9 entre a data de receção de um pedido de mudança reconhecido da Companhia e o respetivo Pedido de Mudança assinada, percebemos a situação em que o Empreiteiro está exposto durante muito tempo.

No caso em que o pedido não é reconhecido como uma mudança ao Contrato, o Empreiteiro deve notificar que este constitui efetivamente uma mudança. So o Empreiteiro não o fizer em tempo útil, perderá o direito a ser compensado por custo / tempo extra.

O Empreiteiro poderá submeter ou diretamente a estimativa de tempo / custo ou declarar que não irá reconhecer tal pedido a não ser que o Cliente A reconheça formalmente como uma Mudança. Isto irá depender da vontade do Empreiteiro de implementar a mudança, o seu impacto e o tempo / esforço requerido para a avaliar.

Assim que a notificação / estimativa acima referida for emitida, deve ser acompanhada de perto a resposta da Companhia.

Esta resposta poderá ser a negação de que o pedido constitua uma mudança. Em tal caso, o Empreiteiro não deverá implementar o pedido.

Há uma excepção a esta situação, quando a resposta do Cliente contem uma instrução formal ao Empreiteiro para implementar a mudança. Os Contratos, usualmente, dão ao Cliente tal direito para forçar o Empreiteiro a cumprir e o Empreiteiro deve cumprir.

O Empreiteiro, então, irá registar os custos incorridos para os reclamar mais tarde ao Cliente.

Quando a resposta não contem uma instrução para cumprir, entretanto, ou se não for recebida resposta do Cliente, o Empreiteiro não deve implementar o pedido.

É essencial um processo bem realizado pelo Empreiteiro de acompanhamento da resposta do Cliente e a comunicação a todas as partes interessadas acerca se sim ou não será implementado o pedido.

Conclusão

É crítico para os Empreiteiros implementar um sistema apertado para detetar os pedidos do Cliente que constituem mudanças ao Contrato. Os Empreiteiros devem implementar efetivamente os pedidos reconhecidos como mudanças ou aqueles que sejam forçados a implementar devido a instrução formal.

A não implementação de tal sistema, o que é muito comum, resulta em perdas significativas para os Empreiteiros.