Actividades insignificantemente fatais

Quantas vezes acontece que um projecto se atrasa porque alguém se esqueceu de uma pequena actividade, quase insignificante, mas intransponível?

Recuperar dessas situações pode ser muito complicado. A responsabilidade será sempre do Gestor de Projecto (GP) pois é a ele que compete garantir a realização das actividades de forma integrada.

O problema é que estas pequenas actividades surgem no projecto (são identificadas ao GP) a propósito de uma actividade central, em situações mais informais (num telefonema, numa conversa), quase como irrelevantes. A razão para essa quase clandestinidade é que, na maioria das vezes para as equipas que as realizam, essas pequenas tarefas são pormenores, tarefas do dia-a-dia.

Prevenir estas situações exige o registo destas tarefas e o seu controlo periódico.

Para mim, não é solução ir acrescentando ao plano do projecto todas estas pequenas tarefas pela sobrecarga que exige ao fragmentarmos muito as tarefas com estes pormenores. Em vez disso, utilizo um registo de log onde identifico e caracterizo as pequenas tarefas.

Para a estrutura do registo do log considero:

· Descrição – descrição sucinta da tarefa

· DataIdentificação – data em que foi identificada

· ResponsávelExecução – Quem é responsável pela execução

· DataConclusão – Data em que a tarefa tem de estar concluída

· Estado – Estado da tarefa {Aberta, Fechada, Em Execução}

· Comentário ao estado – Observação à situação

Normalmente, uso o Excel para manter este registo. No entanto, o suporte não é importante.

Fundamental é partilhar este registo com a restante equipa de projecto.

Como resolvem esta questão? da mesma maneira?

PMI Versus Agile

Na versão tradicional de gestão de Projectos (leia-se PMI, no contexto), o âmbito do projecto é a base sobre a qual se estabelece o contrato entre um fornecedor e um cliente. Alterações ao âmbito dão origem a mudanças, que terão impacto no projecto, nas vertentes de custo, prazo, ou qualidade.
Na formulação ágil de gestão de projectos, o âmbito é essencialmente uma variável de gestão, apenas superficialmente definida, entendida como altamente mutável, sendo por isso o tempo e o custo as bases do contrato. Ou seja, num projecto Ágil, estabelece-se um orçamento, para um determinado tempo de projecto (timebox), no qual será desejável entregar um determinado âmbito, ainda não totalmente detalhado e a clarificar no detalhe, que serviu de base à estimativa de custo e de tempo. Mudanças no âmbito são assumidas ab initio como certezas, por isso a sua pré-definição não é um factor determinante do rigor da gestão.
Assim, em cada fase do projecto (sprint), é detalhado o âmbito concreto, definido o que cabe no tempo definido e negociado, em caso de necessidade, o que sai do âmbito do projecto, para continuarem a ser cumpridas as restrições do projecto: tempo e custo. O que não couber, passa para uma evolução seguinte do projecto.
Necessariamente, algumas expectativas do cliente, se não for clara esta situação, poderão ser goradas. Um produto que não cumpre, mesmo entregue no prazo, é um produto defeituoso.
Apesar das estatísticas sempre referirem que uma parte muito pequena dos projectos cumpre em prazo e em custo, será que as organizações estão verdadeiramente preparadas para aceitar que tudo é, afinal, uma questão de compromisso, resolvida pela gestão ágil?
Ou continua a ser regra que nada no âmbito é para negociar, em face das restantes restrições impostas, a não ser para cumprir o “já agora” que sempre acontece?
E como pode um GP trabalhar de duas formas tão distintas? Como muda o papel para o GP entre PMI e Agile?

Business Case para quê?

Para que serve o Business Case se não existe a posteriori a confrontação dos benefícios identificados com a realidade do Negócio após a realização do projecto?

Em muitas ocasiões, o decisor ao analisar o Business Case, só está interessado em saber se o Break-Even está dentro dos valores que possibilitem a realização do projecto. E, geralmente, não confronta os dados apresentados com a realidade do Negócio nos anos posteriores à implementação do projecto.

Por outro lado, as áreas de Negócio responsáveis pela elaboração dos Business Case, ao saberem que não irá haver confrontação dos benefícios esperados com a realidade do Negócio após a realização do projecto, sentem que podem manipular os dados do Business Case, sobrevalorizando os benefícios e subvalorizando os custos, de modo a fazerem aprovar o projecto que tanto querem, sem que sejam responsabilizados no futuro pela análise realizada.

Para que serve então, um estudo de impacto no Negócio, se as premissas não são realistas?

A confrontação do Business Case com os benefícios qualitativos e quantitativos reais para o Negócio após a realização do projecto, poderia trazer muitos benefícios:
- Possibilita a constante melhoria dos indicadores dos Business Case futuros;
- Responsabiliza as áreas de Negócio pelas análises realizadas;
- Melhora a identificação de projectos que tragam reais benefícios para o Negócio;
- Melhora o planeamento dos futuros projectos.

O Negócio só deveria fechar o dossier do projecto, quando realizasse o estudo dos benefícios reais alcançados pela sua concretização.

PMO

Muitos acham que a implementação de um PMO não é relevante na Gestão de Projectos, outros nem sabem do que se trata. A implementação de um PMO (Project Management Office) deve ser realizada em casos em que os projectos sejam extensos e complexos. Deve ser formado por profissionais que servem as necessidades da Organização em termos de Gestão de Projectos.

Um PMO desempenha diversas funções, tais como:
- fornecer suporte de Gestão de Projectos à equipa de projecto, assumindo tarefas administrativas da calendarização, produção e manutenção do repositório/histórico, de relatórios, ou outra informação do projecto, assim como a sua distribuição ou divulgação;
- desenvolver, manter e promover metodologias/normas, ferramentas e técnicas de Gestão de Projectos por forma a que as Organizações possam melhorar a nível organizacional e realizar projectos de forma consistente;
- ajudar na melhoria da rentabilidade e promover equipas de projecto produtivas.

A verdade é que muitos desconhecem a utilidade/função de um PMO numa equipa de Gestão de Projectos, mas será que depois desta breve nota vão continuar a achar a sua implementação irrelevante?

Business Case, onde começa um projecto...

Tudo começa com uma Ideia que se materializa em Business Case(BC) ou estudo de Viabilidade antes de se transformar em Projecto.

Passo a transcrever a definição de Business Case do Wikipidia:
“A business case captures the reasoning for initiating a project or task. It is often presented in a well-structured written document, but may also sometimes come in the form of a short verbal argument or presentation. The logic of the business case is that, whenever resources such as money or effort are consumed, they should be in support of a specific business need. An example could be that a software upgrade might improve system performance, but the "business case" is that better performance would improve customer satisfaction, require less task processing time, or reduce system maintenance costs. A compelling business case adequately captures both the quantifiable and unquantifiable characteristics of a proposed project.
Business cases can range from comprehensive and highly structured, as required by formal project management methodologies, to informal and brief. Information included in a formal business case could be the background of the project, the expected business benefits, the options considered (with reasons for rejecting or carrying forward each option), the expected costs of the project, a gap analysis and the expected risks. Consideration should also be given to the option of doing nothing including the costs and risks of inactivity. From this information, the justification for the project is derived. Note that it is not the job of the Project Manager to build the business case, this task is usually the responsibility of stakeholders and sponsors.”

Esta definição está correctíssima e acaba muito bem: não faz parte das funções do gestor de projecto elaborar o BC.
No entanto, não são raros os projectos aos quais foi dado o “go” sem BC ou, pior, com base num BC que não reflecte a realidade dos factos, mas o que o sponsor quer ver. Quando o projecto nos chega, já “foi dada a cara” e assumidos compromissos com cliente interno ou externo, pelo que ficamos condenados a gerir projectos mal dimensionados. A partir daí cabe-nos a nós, gestores de projectos, justificar: a necessidade de mais recursos, mais prazo, mais orçamento, o porquê de um NPV (VAL) negativo e de um payback inexistente...

Sinto uma forte resistência em envolver a gestão de projecto na elaboração do BC, tanto do parte das equipas comerciais como dos próprios PMO’s.
Os primeiros até entendo, pois a voz da razão soa como um obstáculo ao desenvolvimento do negócio. Como já ouvi uma vez: “vocês são técnicos e estão aqui para fazer das nossos mentiras verdades...”.
Que os PMO’s não queiram participar na análise de viabilidade dos projectos que irão ter que gerir, custa-me aceitar. Mas então, as lessons learned, todos os históricos de planos, de dimensionamento de equipas, de orçamentos finais, de riscos projectos... enfim, toda essa informação que o PMI tanto preza e que os PMO armazenam ,não deveria ser um dos input para o BC? Se os PMO’s são responsáveis pela gestão de portfólio, onde é que começa? O PMO não deveria querer ganhar força de intervenção na decisão de “go/no go” dos projectos?
É na Ideia e no BC que o projecto nasce, e o que nasce torto tarde ou nunca se endireita...

Datas, quero datas, e já hoje!

A quantos gestores de projecto são pedidas datas de finalização do projecto sem haver uma ideia clara do âmbito do produto?

A principal responsabilidade de um gestor de topo não é pedir datas, ainda mais quando o gestor de projecto não as tem para dar (a não ser que seja um cartomante).

O Gestor de topo deve pressionar para primeiro haver uma clarificação precisa do que se pretende do projecto, este é o passo mais importante para o sucesso, estabelecer a visão, o produto do projecto. Depois exigir planeamento, e rigoroso. E por fim as datas aparecem, e realistas.

Isto é do senso comum mas curiosamente poucos entendem este processo natural.

Penso que este aspecto está intrinsecamente relacionado com a pressão dos dias de hoje para acontecerem resultados, e por vezes essa pressa leva a saltar fases fundamentais para o sucesso de um projecto.

Ninguém pode trabalhar para resultados, podemos é trabalhar nos aspectos que potenciam os resultados. Na gestão de projecto, potenciar os resultados, i.e, o sucesso do projecto, é despender esforço em primeiro definir o âmbito do produto, e só depois planear e executar.

Parece evidente mas será assim tão comum?

Abraham Maslow nasceu a 1 Abril de 1908, faria hoje 102 anos. Defendeu uma teoria baseada na pirâmide das necessidades, hieraquizada em 5 níveis distintos, aplicável à Gestão de Recursos Humanos em todos os projectos.

- No 1º nível estão as necessidades fisiológicas, tais como as condições de trabalho em termos de ambiente físico, infraestrutura, ergonomia, horário de trabalho, etc..
- No 2º nível as necessidades de segurança, relacionadas com à continuidade do trabalho no projecto e em outros seguintes.
- No 3º nível as necessidades sociais, relacionamentos que se estabelecem com as pessoas da equipa do projecto e stakeholders, seja em termos de eventos ou comemorações por hitos alcançados.
- No 4º nível estão as necessidades de autoestima, ou seja, os elogios recebidos pelos profissionais, o reconhecimento, os prémios, bónus, etc...
- O 5º nível é o da autorealização, relacionado com a felicidade e realização por aquilo que se faz.

Ao contrário do que Maslow defendia, por vezes, as necessidades não seguem uma sequência contínua nos 5 níveis e podem sobrepor-se/misturar-se.
Mas se pensarmos num sentido mais lato, seremos movidos apenas por motivações intrínsecas, ou seja, pela vontade de realizar algo que conduza ao alcance do nível cinco?
O 4º nível poderá considerar-se a vontade externa, como um conjunto de estímulos e incentivos para levar à motivação, aos quais cada pessoa reage de maneira diferente?
Maslow afirmava que, quando uma necessidade não é satisfeita, não significará que a pessoa fica frustrada para sempre. De alguma forma, essa necessidade será compensada, pois a motivação é um ciclo constante na vida de todas as pessoas.