O que um Business Case deve levar em conta

Vamos supor que a empresa em que você trabalha pretenda implementar uma mudança que será feita através de um projeto. Antes de começar a tratar desse projeto a alta direção solicita que seja elaborado um business case e você recebeu a missão de realizar essa tarefa. O que o seu business case deve levar em conta é o objetivo desse post.

 

Desenvolver um business case é uma tarefa que vai além de apresentar uma simples planilha que mostre o retorno sobre o investimento estimado no projeto. De fato, os indicadores financeiros como o RoI ("Return on Investment", retorno sobre o investimento), o VPL (Valor Presente Líquido) e a TIR (Taxa Interna de Retorno) são muito importantes, mas será necessário incluir também bons argumentos ou fatores qualitativos que demonstrem a solidez dos números apresentados. Para ser aprovado, o business case deverá passar pelo crivo da alta direção. Se você não estiver pronto para responder perguntas como, por exemplo, “porque devemos aprovar esse projeto”, terá problemas.

Uma das primeiras dificuldades será fazer a estimativa de custos sem ter uma EAP (Estrutura Analítica do Projeto). Embora a EAP seja criada na etapa de planejamento do projeto, como definido nos processos do guia PMBOK, você precisará da melhor EAP que puder conseguir, mesmo antes do projeto ter começado. Você também precisará de um cronograma, mesmo que seja preliminar. Com a EAP será possível entender que entregas o projeto precisará fazer e assim estimar os custos relativos a cada uma delas. Com o cronograma será possível estimar os prazos de execução das atividades do projeto e a duração total estimada para o mesmo.

Não inclua “gorduras” (contingências) nos custos estimados se não tiver uma forte justificativa para tal. Para estimar contingências será necessário trabalhar no plano de gerenciamento de riscos para ter a compreensão do que fazer para responder aos riscos identificados nesse plano e, consequentemente, estimar os custos relacionados às ações de tratamento desses riscos.

Tenha em mente que uma decisão de investimento (o dinheiro que será aprovado pela alta direção para implementar o projeto) deverá se apoiar, em primeiro lugar na maioria dos casos, em resultados financeiros tangíveis (redução de custos, aumento da lucratividade). Os outros fatores qualitativos (intangíveis) que deverão fazer parte do business case são:

·         Obtenção de vantagens operacionais como, por exemplo, algum tipo de vantagem competitiva, aumento da satisfação dos clientes e aumento do moral interno do pessoal;

·         Fatores legais e de “compliance”, como os relacionados a atender a legislação e também as regras de “compliance” (governança corporativa);

·         Fatores humanos, como a melhoria da qualidade de vida que poderá ser obtida como um dos resultados esperados do projeto;

·         Fatores ambientais, como a redução ou eliminação de poluição e outros aspectos que afetem positivamente o meio ambiente.

Um projeto para ser aprovado precisa estar alinhado com as estratégias da organização e é a alta direção que define e cuida dessas estratégias. O seu business case precisa, portanto, fazer sentido para esse grupo de tomadores de decisão. Apresente o que o projeto faz tendo como base a EAP e o cronograma. Use o plano de riscos que será importante para que você comunique que estará pronto para problemas eventuais, caso ocorram, e que saberá lidar com esses problemas. Isso traz confiança e ajuda a fundamentar as contingências estimadas. Apresente os resultados tangíveis esperados e os fatores qualitativos intangíveis. Seja direto e objetivo para que o pacote completo fique gravado na mente das pessoas que fazem parte da alta direção. Mas, se você ainda tem duvidas sobre o que é mais importante no seu business case, tenha certeza de uma coisa: se o seu business case não é bom o suficiente para demonstrar que os fatores tangíveis serão alcançados, o seu projeto não será aprovado. Bem, é isso aí. Até a próxima.

Dica: Novo Site de Ricardo Vargas

Quem trabalha com gestão de projetos já deve ter participado de alguma palestra, lido algum artigo, estudado em algum livro, assistido algum vídeo ou ouvido algum podcast (áudio) de Ricardo Vargas, um profissional reconhecido por sua vasta contribuição na área de gerenciamento de projetos. Um profissional que atuou em mais de oitenta projetos de grande porte em diferentes países, nas áreas de petróleo, energia, telecomunicações, informática e finanças, nos últimos 20 anos. Ricardo Vargas recentemente atualizou a sua home page e a dica desse post é exatamente sobre isso: Acessem o novo site, cujo resultado foi excelente. Vale muito a pena!

Nova versão do site: https://ricardo-vargas.com/pt/

Você encontrará podcasts, livros, downloads, vídeos, artigos, consultorias, treinamentos e workshops. Aproveito para sugerir que ouçam o podcast: O que Faz um “Grande” Gerente de Projetos.

Para você, estudante de gestão de projetos, considere esse um lugar para aprender e encontrar bons materiais para sua pesquisa de TCC. Para você, profissional de gerenciamento de projetos, considere uma fonte segura e confiável de informações atualizadas que o ajudarão no desempenho de sua profissão.

Bem, é isso aí. Até a próxima!

Uma Pesquisa sobre a Gestão das Partes Interessadas

Uma pesquisa recente de Elizabeth Harrin, publicada em abril de 2017, mostra que muitos gerentes de projeto compreendem o valor do gerenciamento das partes interessadas, mas em muitos casos não atuam efetivamente na sua execução.



O que os gerentes de projeto alegam para não fazer o gerenciamento das partes interessadas. Fonte: HARRIN, 2017.

O engajamento das partes interessadas é essencial para o sucesso dos projetos. A pesquisa, realizada através do blog GirlsGuideToPM.com, incluiu respostas de mais de 300 gestores de projetos em todo o mundo. Eles (e elas) relataram que conhecem o valor do gerenciamento das partes interessadas e mencionaram isso citando que:

• Ajuda a gerenciar os riscos;
• Melhora a percepção de sucesso;
• Ajuda a proteger os recursos;
• Garante que a equipe faz o que é necessário.

Fazer corretamente o gerenciamento das partes interessadas vai muito além da obrigação de criar uma lista de pessoas envolvidas e afetadas pelo projeto. É necessário ter a clara compreensão do que cada parte interessada pode fazer para ajudar o andamento do projeto e suavizar a solução de questões a respeito do mesmo. Por outro lado, um stakeholder que não compreende o que o projeto entrega e sua importância para a organização poderá tornar-se alguém que vê o projeto de forma áspera e negativa, podendo prejudicar – voluntariamente ou não - o projeto.

Mesmo assim, a pesquisa mencionada constatou que nem todos os gerentes de projetos são eficazes na gestão das partes interessadas, alegando que - dentre outros motivos - não fazem isso por falta de apoio da alta direção (45%), por falta de tempo (48%) ou por não possuir modelos (templates) que os ajudem nesse processo (27%).

De nada adianta conhecer os processos e as ferramentas de gerenciamento das partes interessadas se estes não são aplicadas na prática. Bem, é isso aí. Até a próxima.

Fonte: HARRIN, E. The Stakeholders Management Survey Results Are In. Disponível em: <https://www.girlsguidetopm.com/the-stakeholder-management-survey-results-are-in/>. Acesso em 30 abr 2017.

Arduino: A tecnologia perto de nós!

Uma das ideias mais bem sucedidas quando pensamos em microcontroladores e eletrônica é o Arduino, uma plataforma de hardware e software para montar protótipos de maneira extremamente fácil e criar projetos. A base de tudo está em uma pequena placa eletrônica de excelente qualidade e baixo custo.

Arduino Uno R3

 

O Arduino trabalha com um software open-source chamado IDE que pode ser baixado gratuitamente. No Arduino é possível conectar sensores – que tem a função de medir o que acontece – e atuadores – para agir e controlar.  Confuso? Vejamos um exemplo. Digamos que você gostaria de melhorar a proteção da sua casa. Você percebeu que existe certo risco e decidiu criar um alarme de presença para ser instalado bem na entrada. O sensor será um PIR (Passive InfraRed), sensor de movimento e presença do tipo infravermelho. O Arduino identifica quando o sensor PIR é acionado – pela presença de alguém - e aciona uma sirene (que é o elemento que dá o alarme). Para ligar e desligar a sirene vamos usar um modúlo relé. Há vários desses módulos que funcionam com o Arduino. Pronto, já temos o nosso projeto. Para que tudo isso funcione é necessário carregar um programa no Arduino que chamamos de sketch. Se algo estranho acontece, causado por elementos indesejados, o sistema se mostrará de grande utilidade. Um projeto de qualidade, baixo custo e executado com facilidade. A filosofia básica do Arduino é, em linhas gerais, definir os sensores que irão medir o que acontece no ambiente, depois definir os atuadores que irão ligar, desligar e acionar, e finalmente, escrever um sketch que faça tudo isso funcionar!

Agora o seu projeto é fazer um termostato que funciona abrindo ou fechando um contato elétrico de um relé quando a temperatura atinge um determinado valor previamente ajustado. Ajustei, por exemplo, o termostato para 28 graus. Quando a temperatura aumenta e atinge 28 graus um contato de relé será acionado. Nesse exemplo, o sensor será um sensor de temperatura (existem vários que funcionam com o Arduino). O Arduino mede o sinal desse sensor e verifica se a temperatura atingiu o limite ajustado. Quando a temperatura atinge o valor pré-definido (ajustado no programa) o Arduino envia para uma saída um sinal para acionar um relé. O relé é o atuador de abre ou fecha um contato elétrico. Da mesma forma, para que tudo isso funcione é necessário carregar um programa no Arduino (um sketch).

Podemos dizer que os dois exemplos mostrados acima são típicos. Algo que qualquer pessoa pode fazer com um bom treinamento sobre essa tecnologia. Há milhares de projetos elaborados tendo o Arduino como elemento de controle, desde os mais simples (como acender uma lâmpada com o controle remoto da sua TV e os mencionados nos exemplos anteriores) até os mais complexos, como os relacionados à robótica e ao controle da operação de impressoras 3D (vídeo).

 

Em outras palavras, a tecnologia é boa, e podemos tirar proveito dela, quando está perto de nós. Esse é o caso do Arduino. É possível aprender sobre o Arduino e como trabalhar com essa tecnologia, pois é algo que está ao nosso alcance. Como sempre o difícil é começar, dar os primeiros passos. E é verdade que os primeiros passos, quando bem dados, ajudam a gente na estrada inteira. Uma boa dica são os treinamentos presenciais. Bem, é isso aí. Até a próxima.

A Gestão de Riscos em Projetos - O Fluxo

Como dissemos anteriormente, a base dos métodos de gerenciamento de riscos em projetos se apoia na identificação, análise e no tratamento dos riscos.  A figura abaixo apresenta um fluxo das ações relacionadas ao gerenciamento dos riscos em um projeto.

Fluxo de Gerenciamento de Riscos em Projetos

 

Iniciamos com a identificação dos riscos utilizando técnicas como, por exemplo, a opinião especializada, a análise de premissas e a EAR (Estrutura Analítica de Riscos). Essas técnicas nos ajudam na identificação dos riscos com o objetivo de determinar quais riscos podem afetar o projeto e documentar as características de cada um, sendo um processo realizado ciclicamente ao longo do projeto e não apenas uma vez, no início do projeto. O resultado da identificação de riscos é uma lista contendo os eventos de risco, apresentando as ocorrências específicas que devem ser identificadas no contexto das fontes de riscos e os sintomas de riscos (“triggers” = gatilhos), que são manifestações indiretas de eventos de risco reais. Em outras palavras, não basta apenas criar uma lista com os riscos do projeto. Para cada risco será necessário compreender o que pode fazer com que esses riscos aconteçam.

É de fundamental importância identificar os riscos, analisá-los qualitativamente e quantitativamente e, como um praticante da verdadeira gestão proativa, estabelecer formas de lidar com essas ameaças e oportunidades. Quando se analisa os riscos de um projeto é muito importante conhecer, além das características técnicas do mesmo, as pessoas, processos e sistemas da organização. Tendo em mãos essas entradas será possível aplicar ferramentas qualitativas e quantitativas para análise de riscos.

A análise qualitativa de riscos é, geralmente, um meio rápido e econômico de estabelecer prioridades. Os riscos que exigem respostas à curto prazo podem ser considerados mais urgentes. Com base nas prioridades obtidas com a análise de riscos devemos rever o nosso documento de riscos versus gatilhos.

Durante a execução do projeto os gatilhos de riscos serão monitorados. Isso está representado no fluxo pela pergunta: - Gatilho de risco ativado? Se sim, passamos para a etapa de responder conforme estabelecido no plano de riscos. Se não, passamos para a próxima pergunta que é a seguinte: - Há necessidade de nova rodada de identificação? Se sim, isso significa que houve alguma mudança que justifica uma atualização na identificação de riscos e, consequentemente, no documento que mostra os riscos versus gatilhos. Se não, seguimos para a pergunta: - Projeto encerrado? Se sim, o projeto é finalizado. Se não, voltamos para a monitoração dos riscos, pois o projeto ainda se encontra na etapa de execução. Isso é feito continuamente até que todas as entregas do projeto sejam feitas e o projeto seja encerrado.

O gerenciamento de riscos em projetos é um processo dinâmico e difícil de ser traduzido por um desenho de fluxo. Essa tentativa teve a intenção facilitar a compreensão desse processo pelo estudante. Nesse sentido, as sugestões e críticas dos leitores serão muito bem vindas. Bem, é isso aí! Até a próxima.

Fernando Pessoa: Tudo vale a pena!

Fernando Pessoa (1988-1935) foi um homem de múltiplos talentos e um escritor incomparável que é considerado o maior poeta de língua portuguesa. A obra e a biografia do autor podem ser encontradas na Internet em muitos sites. O que interessa aqui nesse espaço é compartilhar alguns momentos que valem muito a pena!

Em Lisboa, em frente ao Café A Brasileira, junto ao Largo do Chiado, foi inaugurada, nos anos 1980, uma estátua de bronze que representa o escritor sentado à mesa na esplanada do café. Para a legião de leitores e admiradores é uma forma de sentir-se próximo, uma vez que o autor era frequentador assíduo do lugar. E, mesmo que só na imaginação, sentar-se ao lado para admirar, ou mesmo para tirar uma foto, é uma forma de matar a saudade, mesmo para alguém que nunca o tenha conhecido, mas que foi impactado por sua incrível poesia. Como nas palavras de um autor desconhecido, “a saudade é a maior prova de que o passado valeu a pena”.

 

 “O valor das coisas não está no tempo que elas duram, mas na intensidade com que elas acontecem. Por isso existem momentos inesquecíveis, coisas inexplicáveis e pessoas incomparáveis”.

...............................

“O poeta é um fingidor.
Finge tão completamente
Que chega a fingir que é dor
A dor que deveras sente.

E os que leem o que escreve,
Na dor lida sentem bem,
Não as duas que ele teve,
Mas só a que eles não têm.

E assim nas calhas de roda
Gira, a entreter a razão,
Esse comboio de corda
Que se chama coração”.

 

 “Tudo vale a pena se a alma não é pequena”.

...............................

 “Matar o sonho é matarmo-nos. É mutilar a nossa alma. O sonho é o que temos de realmente nosso, de impenetravelmente e inexpugnavelmente nosso”.

...............................

A Gestão de Riscos em Projetos – Riscos x Gatilhos

A base dos métodos de gerenciamento de riscos em projetos se apoia na identificação, análise e no tratamento dos riscos. Essa forma de trabalhar não é exclusiva do guia PMBOK, podendo ser observada em outras abordagens como, por exemplo, o RUP (Rational Unified Process), o método de Boehm, a norma ISO31000, e o CMMI(Capability Maturity Model Integration). Os nomes podem variar um pouco, aqui e ali, mas a essência é sempre a mesma: identificação dos riscos, análise dos riscos e tratamento dos riscos.

Durante o planejamento do projeto os riscos são identificados e analisados. O resultado dessa análise nos leva a estabelecer as estratégias de tratamento dos riscos identificados. Durante a execução do projeto os riscos são monitorados. O resultado desse monitoramento nos leva a decidir sobre a necessidade de seguir adiante, ou não, com as ações de tratamento dos riscos.

A identificação dos riscos é um passo fundamental. Segundo o guia PMBOK, 5ª. edição, o resultado do processo de identificação dos riscos do projeto é o registro dos riscos, que inclui uma lista dos riscos identificados com o maior número de detalhes possível. Devem fazer parte dos resultados da identificação dos riscos as condições ou eventos que podem provocar esses riscos. Em outras palavras, não basta apenas criar uma lista com os riscos do projeto. Para cada risco será necessário compreender o que pode fazer com que esses riscos aconteçam. Vamos refletir sobre alguns exemplos para esclarecer melhor esse conceito.

Vamos supor que o gerente de projetos está preocupado com a piora no desempenho da equipe, pois isso pode provocar atraso na execução de atividades e, consequentemente, atraso no cronograma do projeto. Certamente, isso deve fazer parte da lista de riscos identificados do projeto. O risco é a piora no desempenho da equipe. Todavia, o gerente de projetos não quer monitorar apenas isso. Certamente, o desempenho da equipe será monitorado e serão feitas comparações entre o trabalho planejado versus realizado. Além disso, o gerente de projetos precisa encontrar algo para monitorar que o ajude a antecipar uma piora no desempenho da equipe do projeto, antes que essa piora realmente aconteça. Assim sendo, o gerente de projetos terá algum tempo para reagir e tentar evitar que o risco realmente ocorra. Portanto, a pergunta que deve ser feita em seguida é a seguinte: - O que deve ser monitorado que nos permita antecipar uma piora do desempenho da equipe do projeto? A resposta para essa pergunta irá determinar que condições ou eventos serão capazes de disparar o risco de uma piora do desempenho da equipe do projeto.

A saída de um funcionário-chave, bastante experiente e que conheça profundamente o trabalho a ser executado, é um desses fatores. Se esse profissional deixa a empresa ou o projeto, temos um gatilho que dispara o problema. Criar boas condições de trabalho para esse funcionário-chave no ambiente do projeto é uma forma de manter o colaborador comprometido e satisfeito. Outra alternativa é conceder um bônus em dinheiro por alcance de resultados do projeto. O funcionário-chave permanece no projeto porque deseja ganhar esse bônus. Estas são ações de um plano que poderão ser discutidas pela equipe do projeto quando as estratégias de tratamento de riscos estiverem sendo estabelecidas.

Outra condição capaz de piorar o desempenho da equipe do projeto é o aparecimento de conflitos internos, gerados por atritos entre pessoas da equipe com divergências de opinião sobre o que fazer e como fazer. Os conflitos podem ser positivos quando motivam pessoas a resolverem problemas em conjunto e, induzem à descoberta de novas ideias e maneiras de trabalhar. Mas nem sempre é assim. Se o ambiente do projeto tem muitos conflitos, que geram tensão excessiva entre os envolvidos, isso acaba dificultando o alcance das metas e criando situações que resultam em desperdício de tempo e esforço. Em outras palavras, os conflitos em excesso são também gatilhos capazes de provocar uma piora do desempenho da equipe do projeto. O gerente de projetos deve estar atento ao clima da equipe e ser capaz de perceber os sinais de discórdia. Há diferentes motivos para o aparecimento de conflitos como, por exemplo, discordâncias quanto as prioridades, quanto as formas de trabalhar, quanto a decisões técnicas, quanto as estimativas e quanto aos prazos das atividades. Depois que o conflito foi criado será necessário negociar com as partes envolvidas e o estrago estará feito. Mas não é esse o objetivo. A ideia é evitar que o conflito se estabeleça, mantendo a comunicação com a equipe boa o suficiente para que todos compreendam como o trabalho deve ser feito, quem faz o que, quem é responsável pelo que e quem toma das decisões.

 

A tabela acima – que é apenas um exemplo, podendo ser completada e melhorada - apresenta uma lista de riscos típicos de um projeto que inclui, além do risco de piora no desempenho da equipe, riscos relacionados ao atraso de fornecedores, aos erros nas estimativas, a diminuição do apoio de importantes stakeholders, ao atraso devido as condições meteorológicas, ao atraso por queda de energia, ao atraso devido a falhas no sistema de TI, a insistência do cliente em incluir itens no escopo previamente acordado, a lentidão no sistema de aprovação do cliente, a erros na especificação dos requisitos, ao nível baixo de autoridade do gerente de projetos na estrutura hierárquica da organização e ao risco de demora da diretoria na aprovação de gastos para o projeto.  A tabela mostra para cada risco identificado um campo dedicado ao gatilho ou gatilhos que precisam ser monitorados. A tabela foi deixada incompleta de propósito para desafiar o leitor a completá-la e aprimora-la.

Gostaria de concluir sugerindo a leitura do post “Um Exemplo de Identificação de Riscos”, que além de tratar a etapa de identificação, desenvolve o conceito da análise qualitativa de riscos. Bem, é isso aí! Até a próxima.