Abril 19, 2019

Login to your account

Username *
Password *
Remember Me

Create an account

Fields marked with an asterisk (*) are required.
Name *
Username *
Password *
Verify password *
Email *
Verify email *
Captcha *
Reload Captcha

PROJETOS E AS EMPRESAS

Certamente programas e projetos existem em toda empresa, em diversos tamanhos, e vários em operação atualmente. Portanto eles estão sendo gerenciados de alguma forma na empresa.

Em grandes organizações haverá ilhas de gerenciamento de projetos. Isso frequentemente resulta num mar de práticas isoladas para gerenciar cada projeto, assim como em sistemas de informação conflitantes e sobrepostos.

Atualmente há um consenso de que gerenciamento de projetos é o que existe de mais moderno dentro de muitas empresas e agências governamentais para promover iniciativas de forma profissional.

Como resultado, executivos seniores de empresas de todos os tamanhos são exigidos por conhecer essa forma de gestão, e devem saber quais pontos podem exigir de seus gerentes e equipes para atingir uma excelência na forma como seus programas e projetos são criados, selecionados para financiamento, planejados e executados.

Entre essas demandas dos executivos aos gerentes de projetos estão também relatórios que mostrem o quão bem os benefícios esperados dos programas e projetos foram atingidos.

O QUE OS EXECUTIVOS DEVEM DEMANDAR DOS PROJETOS:

Demandas Estratégicas

1 – Todo programa e projeto autorizado claramente apoia um objetivo estratégico aprovado da organização.

2 – Todas as inovações significativas são realizadas através da aplicação dos princípios de gerenciamento de projeto, programa e portfólio.

3 – Cada risco é gerenciado utilizando-se métodos e sistemas atualmente disponíveis.

4 – Todos os projetos são avaliados, priorizados e aprovados com base no mesmo critério corporativo.

Demandas de Processos de Gerenciamento de Projetos

5 – Os processos de gerenciamento de programas, projetos e portfólio da organização são documentados de maneira coerente, facilmente entendida.

6 – Todos os projetos são geridos dentro dos portfólios definidos apropriadamente.

7 – A disciplina e os sistemas de apoio ao gerenciamento de projetos são completamente integrados com as partes afetadas da organização.

8 – É necessário ter um sistema para gerenciamento ativo dos projetos selecionado e implementado no nível mais eficaz possível (portfólio do projeto ou empresa total).

Demandas de Papéis e Responsabilidades

9 – Todos os papéis integrados estão claramente definidos, compreendidos e designados a pessoas qualificadas.

10 – Um grupo de coordenação de portfólio está indicado para cada portfólio de projeto.

11 – Um patrocinador executivo está indicado para todo grande projeto e portfólio.

12 – Um experiente gerente de projetos está indicado para cada PMO.

13 – Estruturas apropriadas (PMOs) são estabelecidas dentro da organização para a disciplina de gerenciamento de projetos.

Demandas de Autoridade e Treinamento de Gerentes

14 – Todos os principais gerentes de projetos e programas passam por treinamento necessário para assegurar seu desempenho eficaz.

15 – Cada gerente de projeto respeita as linhas funcionais de autoridade quando a direção do projeto é dada aos membros de suas equipes.

16 – Gerentes funcionais (linha) e líderes de projetos respeitam as linhas de projeto de autoridade conforme exercitado pelos gerentes de projetos.

Demandas de Controles de Projetos

17 – Todo projeto é planejado e controlado dentro das linhas guias especificadas na documentação de processos de gerenciamento de projetos corporativos.

18 – Todos os sistemas e procedimentos de controle e planejamento dos projetos são integrados de modo que todas as informações do projeto sejam atuais e consistentes ao longo de toda a organização.

19 – Apenas um sistema de controle e planejamento de projetos sintetizador é usado ao longo de toda organização.

20 – Os métodos de previsão e avaliação do progresso do valor agregado são aplicados em todos os principais projetos.

21 – O processo de gerenciamento de projetos coorporativo inclui uma detalhada descrição do sistema de controle e informação do gerenciamento de projetos corporativos.

22 – Todos os módulos técnicos, de risco e de informação do projeto são incluídos no processo de gerenciamento de projetos corporativo e no sistema de controle e informação corporativa geral.

23 – Todos (com exceções especificamente aprovadas) os documentos relatados são produzidos pelos sistemas de software de assistência.

24 – os conceitos de projeto/ estrutura analítica do projeto (P/ WBS) e gerenciamento de interface do projeto são aplicadas para alcançar um nível eficaz e sustentável de detalhes na documentação do projeto.

Demandas da Equipe de Projeto

25 – Uma lista completa da equipe do projeto é produzida e distribuída para todos os membros-chaves da equipe.

26 – Cada equipe do projeto desenvolve uma declaração dos objetivos do projeto que todos os membros das equipes entendem e apoiam – consistente com os objetivos “oficiais” do projeto – dentro de duas semanas após a formação das equipes.

27 – As equipes do projeto estabelecem critérios brandos e rígidos para o sucesso do projeto aos olhos das suas partes chaves interessadas.

28 – Cada equipe estabelece um plano de projetos tangível com o qual todos os membros das equipes estão comprometidos.

29 – A documentação do processo de gerenciamento de projetos corporativos inclui os procedimentos necessários para assegurar um trabalho em equipe eficaz.

30 – Gerentes de projetos recebem treinamento de liderança apropriado antes de serem colocados no comando de qualquer grande projeto.

Demanda Pós-Conclusão do Projeto

31 – Uma apreciação pós-conclusão é desempenhada em todo projeto para 1) determinar se os benefícios do plano de negócios do projeto foram alcançados, 2) documentar as lições aprendidas, e 3) melhorar os processos, práticas e procedimentos de gerenciamento de projetos corporativos.

Ao colocar essas demandas para os gerentes de projetos e suas equipes o executivo expressa um comunicado à empresa inteira de que a melhor gesão é aquela que compreende o que é necessário para se alcançar o melhor desempenho possível através da seleção e do gerenciamento dos seus projetos e programas, e que essa gestão apoia totalmente a melhoria contínua, necessária para perpetuar o sucesso da empresa.

O gerenciamento de projetos é agora uma capacidade vital para todas as empresas que desejam Inovar. Certamente a disciplina de gerenciamento de programas e projetos é uma importante área de especialização que, de fato, se tornou uma profissão de gestão dentro de todo o campo da administração empresarial.

 

Compartilhe nas redes sociais:

INTRODUÇÃO

O gerenciamento de prazos em projeto evoluiu significativamente desde o desenvolvimento do Gráfico de Gantt no começo do século 20, do Método do Diagrama de Precedência em meados do século passado e da CCPM (Critical Chain Project Management. A evolução dos microcomputadores e seu softwares facilitou o uso e a popularização dessas técnicas na gestão de projetos.

O conceito de “valor agregado” começou a surgir ainda no início do século 20, em boa parte com base no princípio do “tempo agregado”, popularizado por Frank e Lillian Gilbreth. Nos anos 1960, o departamento de defesa do governo norte-americano o utilizou na criação da técnica PERT/ COST, que evoluiu para a C/ SCSC – Cost/ Schedule Control System Criteria e desembocou, no final dos anos 1970, no EVM – Earned Value Management – traduzido para o português como Gerenciamento do Valor Agregado ou GVA.

O sucesso do GVA, como metodologia de gerenciamento de projetos, é amplo na gestão de custos mas limitado na de cronogramas/ prazos. Isso se deve às idiossincrasias de seus indicadores de prazo (ocorre falha nos indicadores na porção final do cronograma) que geraram descrença quanto a sua aplicabilidade. Atualmente o GVA é utilizado, quase exclusivamente, no gerenciamento de custos.

O Prazo Agregado (PA), técnica criada em 2003 por Walt Lipke, modifica a maneira de calcular os indicadores de prazo, a partir da curva S de custos do GVA, para eliminar suas deficiências. Todavia, como será demonstrado, embora os novos indicadores sejam evidentemente melhores, a utilização de dados de custos no seu cálculo ainda resulta em informações nem sempre confiáveis.

A CURVA S DO GVA E SEU USO NO PA

Considere-se o Projeto A: levantar um muro de 2000 tijolos, planejado para durar 10 dias por um pedreiro que trabalhe, na média, 4 horas por dia. Esse projeto consta, então, de apenas uma atividade que se estende do dia 1 ao dia 10 do projeto. Suponha que o custo por hora do pedreiro seja R$ 20,00. Isso resulta num orçamento para o projeto de R$ 80,00. Nessas condições, a cada dia o pedreiro deve assentar 200 tijolos e receber R$ 80,00 por dia de trabalho. A Tabela 1 sumariza a evolução planejada do custo do Projeto A pelos seus 10 dias de duração, e está representada também na Figura 1.



 

A linha na Figura 1, uma reta, é conhecida, no jargão de gerenciamento de projetos, por “Curva S”. Ela é um gráfico que relaciona duas variáveis: tempo e custo ou esforço (na maioria dos casos), ou tempo e durações totais (como veremos!). Num projeto simples como esse, ela se torna uma reta. Em projetos com mais atividades, o mesmo processo de construção resultaria numa curva cujo início teria inclinação pequena – refletindo o fato de que os projetos começam num ritmo mais lento de crescimento do custo e alocação de pessoal e materiais – em seguida a inclinação da curva aumenta – nos períodos com mais atividades e geralmente maior ritmo de crescimento do custo – e, mais tarde, quando o projeto entra na sua fase final – o ritmo de dispêndios tende a se reduzir.

A medição do trabalho realizado a cada dia foi feita considerando o número de tijolos assentados multiplicado pelo custo por tijolo assentado R$ 0,40 (ou seja R$ 80,00/200). O valor de R$ 120,00, no segundo dia, significa que até o fim desse dia a execução do projeto correspondia ao que fora planejado para a metade do segundo dia. No terceiro dia, a execução estava um dia atrasada em relação ao planejado e, em vez de ter cumprido o valor de R$ 240,00, apresentava o valor medido (VA) de apenas R$ 160,00, que fora planejado para o fim do segundo dia. E assim por diante até o fim do quinto dia, quando o valor medido (R$ 256,00) fora planejado para ocorrer em algum instante no terceiro dia.

A linha vertical no dia 5 indica o momento em que o gerente do projeto emitiu seu relatório de status. A linha verde representa os valores planejados, os mesmos mostrados na Tabela 1. A linha vermelha corresponde aos custos reais acumulados ao final de cada período. A linha azul é o resultado dos valores medidos do trabalho planejado efetivamente executado até o dia 5.

Esse exemplo simples objetivou introduzir a base do que, em gestão de projetos, recebe o nome de gerenciamento do valor agregado.

O período 5, no qual foi feita a medição atual, é denominado Tempo Real (TR) ou Duração Real (DR) e representa o tempo decorrido desde o início do projeto. O valor do orçamento acumulado até o término de um período é chamado de Valor Planejado (VP) daquele período. No caso acima, o VP para o período 5 (R$ 400,00) é o valor acumulado até o final desse período. O VA (R$ 256,00) corresponde, em termos dos valores planejados, ao que foi efetivamente realizado até o dia 5. O CR (R$ 536,00) representa os custos reais acumulados ao final do período 5. O valor total orçado para o projeto A, R$ 800,00, recebe o nome de Orçamento no Término (ONT).

A diferença entre o Valor Agregado e o Custo Real (VA – CR) num determinado ponto de medição é conhecido por Variação em Custos (VC). A diferença entre o Valor Agregado e o Valor Planejado (VA – VP) recebe o nome de Variação em Prazo (VPR). No entanto, embora indique prazo, sua unidade de medição é monetária (isso tem sido objeto de críticas na comunidade envolvida com gestão de projetos). O quociente do Valor Agregado pelo Custo Real é conhecido como Índice de Desempenho em Custos (IDC = VA/ CR) e a razão entre o Valor Agregado e o Valor Planejado é chamado de Índice de Desempenho em Prazo (IDP = VA/ VP). Assim temos:

• Variação em Custos: VC = VA – CR;
• Variação em Prazo: VPR = VA – VP;
• Índice de Desempenho em Custos: IDC = VA/ CR;
• Índice de Desempenho em Prazo: IDP = VA/ VP.

 

Compartilhe nas redes sociais:

Os Problemas em Projetos

Novembro 02, 2018

INTRODUÇÃO

Por que as estatísticas apontam que entre 70% e 80% dos projetos fracassam? O que faz com que projetos planejados detalhadamente e executados por gerentes de projetos qualificados não atinjam seus objetivos?

Após conhecer histórias mal sucedidas, é comum escutar gestores argumentando que as falhas poderiam ter sido evitadas com a correta aplicação de tal ou qual metodologia de gestão de projetos. Porém, a história contém muitos exemplos de projetos em que falhas aconteceram apesar da correta aplicação de metodologias e processos. O caso do Titanic é um dos mais famosos, tem cativado as pessoas por mais de 100 anos e ainda surpreende como um megaprojeto do qual se esperava tanto, não tivesse um final tão trágico.

CONTEXTO

Nas décadas de 1910 e 1920, estava no auge da imigração de europeus para as Américas fugindo da fome e da pobreza. Isso representou um momento de oportunidades para as empresas de transporte de passageiros, entre elas a White Star, do Reino Unido.

A White Star encontrava-se na urgência de melhorar sua rentabilidade num mercado altamente competitivo.

Nesse cenário, não podendo competir com velocidade, a decisão estratégica da White Star foi se diferenciar oferecendo uma experiência luxuosa nas viagens transatlânticas, e foi na implementação dessa estratégia que nasceu o projeto Titanic.

Ao convergir esse clima de modernismo com uma campanha de marketing ousada, gerou-se um otimismo inquestionável que originou a crença de que o novo produto, o Titanic, seria o maior navio da história, o mais moderno, e que graças às novas tecnologias seria impossível naufragar.

Exigiram que fosse reduzido o número de botes salva-vidas, entre outras razões, para favorecer a vista das varandas panorâmicas. Havia em torno do Titanic uma atitude de excesso de confiança e arrogância que chegou ao ponto de considerar o navio tão seguro que nem precisaria de botes salva-vidas, pois não achavam provável um acidente acontecer.

O sacrifício das funcionalidades de segurança levou ao pedido de demissão do gerente dos estaleiros e principal arquiteto de navios da empresa fabricante, Alexandre Carlisle.

Seu substituto, feliz pela promoção e no desejo e agradar seus chefes, não questionou nenhum dos requisitos impostos. Foi nesse contexto que se fez efetivo um fenômeno chamado de bandwagon effect – em português podemos traduzir a expressão como “efeito manada”, que se refere a situações nas quais as pessoas fazem as coisas só porque os outros estão fazendo, seguindo-as sem questionar o pensamento coletivo.

Foram acomodadas alterações que o Ismay, presidente da empresa cliente, solicitou na última hora. Diante dessa realidade, restou somente um dia para fazer os testes do navio no mar, quando o recomendável seriam quatro semanas. Mas o clima de confiança tinha se espalhado para além das equipes envolvidas se espalhado para além das equipes envolvidas no projeto, ao ponto de o fiscal responsável emitir o certificado de segurança do navio após meio dia de testes apenas.

Durante a execução da viagem, algumas tensões surgiram entre as equipes. Os vigias do mastro não possuíam binóculos para poder monitorar as águas e identificar icebergs com antecedência. Essas ferramentas de trabalho estavam guardadas num armário de responsabilidade de um oficial que havia sido dispensado da tripulação um dia antes do navio zarpar. Essa alteração de último momento foi feita sem seguir o devido processo de transição de cargo e por essa razão as chaves do armário não foram entregues para o novo responsável.

Após o impacto com o iceberg, duas equipes foram escaladas para avaliar os danos. A primeira retornou após 10 minutos indicando que não havia danos sérios, provavelmente uma atitude de negação movida pela exagerada confiança na segurança do navio. O presidente da White Star, preocupado com o futuro da empresa, não esperou o reporte da segunda equipe e considerou a avaliação dos danos como encerrada, passando a pressionar a aceleração do navio. O capitão, quem realmente teria autoridade para tomar esse tipo de decisão, não quis questionar o homem poderoso que o havia colocado no cargo. Por causa disso, levou 16 minutos para aceitar que havia um problema e ordenar a preparação dos botes salva-vidas e evacuação dos passageiros. Foi assim que começou o naufrágio que custou a vida de 1517 pessoas na maior tragédia naval em tempos de paz.

FATORES DE INSUCESSO

O caso Titanic nos permite observar como há fatores que contribuem ao sucesso ou fracasso de projetos não relacionados aos processos, mais sim ao aspecto humano. Independentemente da boa aplicação de metodologias, sempre haverá problemas pessoais no ambiente de trabalho a serem resolvidos e que exigirão do gerente habilidades para administrá-los.

Um ambiente horizontal e não vertical, focada nos objetivos, com liberdade para a troca de ideias teria evitado que as pressões comerciais e a atitude arrogante do presidente da companhia direcionassem o desenho do navio. Propiciar espaço para livre discussão, em lugar de imposição do ponto de vista da liderança, teria permitido questionar o otimismo infundado que tomou conta do time do Titanic.

Dentro das competências gerenciais, as atitudes têm sido destacadas como fator-chave de sucesso. Um reflexo da crescente importância das atitudes dos gestores nos projetos foi a inclusão do item “Maturidade emocional” na lista dos 10 fatores-chave para o sucesso de projetos de TI, divulgado no relatório Chaos summary for 2010.

Na sequência a lista completa de fatores-chave:

1. Suporte executivo
2. Envolvimento do usuário final
3. Objetivos claros de negócio
4. Maturidade emocional
5. Otimização do escopo
6. Processos ágeis
7. Expertise em Gestão de Projetos
8. Recursos especializados
9. Execução
10. Ferramentas e Infraestrutura

As pesquisas elaboradas pelo Standish Group identificaram “5 pecados capitais” que costumam estar presentes nos projetos, exigindo um esforço do gestor para administrá-los. Esses pecados são apresentados na sequência.

Pecado 1: Excesso de ambição

Ambição é o desejo de executar um projeto significativo para obter fama, fortuna ou poder pelo impacto de exceder os objetivos do projeto, tentando conseguir muito em pouco tempo.

Pecado 2: Arrogância

Arrogância é o orgulho autoritário injustificado ou hubris, evidenciado por uma conduta de superioridade em relação aos superiores, colegas e subordinados. Hubris é quase sempre acompanhada de falta de conhecimento, interesse e estudo dos fatos, combinado com a falta de humildade.

Pecado 3: Ignorância

Acontece pela falta de informação sobre projetos, detalhes, direções, objetivos dos stakeholders, problemas e oportunidades. É comum a prática da “ignorância racional”, que acontece quando o custo de educar-se a si mesmo sobre um problema, o suficiente para tomar uma decisão informada, supera o benefício potencial dessa decisão. Portanto, parece irracional investir tempo aprofundando o entendimento, uma vez que o benefício da decisão é menor do que o custo das análises.

Pecado 4: Abstinência

Consiste em abster-se de participar ou contribuir. A abstinência pode ser causada pela falta de engajamento ou por falta de entendimento dos objetivos. Existe um caso particular de abstinência que caracteriza o estilo de gestão chamado de laizzes-faire, em que o gerente se omite e delega tudo para sua equipe, servindo apenas de ponte entre o cliente ou a diretoria e sua equipe, sem assumir responsabilidade pelos resultados.

Pecado 5: Fraudulência

Fraudulência é a ação que intenta enganar, deliberadamente e de forma truculente, ganhar alguma vantagem ou evitar confrontação. Fraudulência é o oposto da verdade, no discurso e nas ações. Muitas empresas têm sido afetadas ao criar uma cultura de “boas notícias”, em que os reportes são sempre positivos e os problemas são omitidos, caracterizando uma atitude fraudulenta.

O projeto Titanic do começo do século passado nos permite ilustrar as atitudes que foram identificadas como fontes de falhas por pesquisas elaboradas recentemente. Isso nos permite visualizar a complexidade das situações geradas pelas relações humanas no ambiente do projeto. Essas situações exigem do gestor domínio de habilidades para lidar com assuntos comportamentais. Quais seriam essas habilidades?

Ranjit Sidhu (2012) menciona uma série de tópicos que um gestor precisa administrar nos projetos, o que exige habilidades para:

• Balancear poder e autoridade;
• Derrubar barreiras na comunicação;
• Influenciar percepções;
• Gerenciar as etapas no desenvolvimento das equipes;
• Identificar pensamentos enviesados, tais como “pensamento em grupo” e “efeito manada”;
• Identificar a dinâmica dos stakeholders e os tipos de poder presentes.

A alta porcentagem de projetos que não atingem seus objetivos vem acompanhada por uma quantidade proporcional de explicações. No caso do Titanic, é comum atribuir a causa do naufrágio ao impacto com o iceberg. Da mesma forma, é comum atribuir a causa de fracasso de um projeto a “problemas não previstos”, como atrasos dos fornecedores, rotatividade das equipes, projeções que não se comportaram como esperado, a economia que não cresceu como previsto, etc. Porém, no caso do Titanic a falha não foi o impacto no iceberg e sim a incapacidade dos envolvidos para evitar a colisão.

Como podemos evitar as falhas que as metodologias de projeto não contemplam? É de se imaginar que a resposta não é simples, pois não existe outra “metodologia” para administrar o que foge do alcance das metodologias. Precisamos lembrar que gestão não é uma ciência exta, em parte porque depende dos fatores humanos. Sem esquecer essa limitação, exporemos algumas singelas recomendações que podem contribuir a melhorar expressivamente os resultados dos projetos.

• Reconhecer a importância das atitudes do gestor. Dentro do CHA de todo profissional, tão importantes quanto o conhecimento e as habilidades são as atitudes.
• Assumir a responsabilidade pelos resultados. Essa mudança de atitude é um dos princípios do coaching pessoal. Podemos escolher entre culpar sempre os icebergs, como no caso do Titanic, ou nos prepararmos para evita-los, como fizeram os outros navios.
• Reconhecer vieses cognitivos: precisa-se ter consciência de que nosso pensamento pode estar enviesado e que existem dezenas de processos mentais que nos impedem de agir com racionalidade. Precisamos conhecer esses vieses cognitivos, pelo menos os mais comuns: efeito manada, o viés de confirmação, em que somente se enxergam os fatos que favorecem nossa opinião. O gerente precisa também combater as atitudes identificadas como causas de falhas nos projetos, já mencionados.
• Planejar para evitar falhas: o gerente de projetos não pode limitar-se a fazer a gestão dos riscos, pois, como vimos neste artigo, precisa estar atento para identificar atitudes e formas de pensar que possam comprometer a forma como os riscos são enxergados.

O gestor precisa garantir que os riscos não estão sendo minimizados, por exemplo, por causa de um otimismo irracional, por fraudulência ou pela arrogância dos envolvidos no projeto.

 

Compartilhe nas redes sociais:

1 – INTRODUÇÃO

Para quem trabalha no ambiente de planejamento sabe que é fundamental o exercício analítico na busca de qual será, dentre as diversas alternativas, o caminho de maior chance de sucesso para se realizar alguma coisa ou alcançar um objetivo. O maior valor no planejamento é o exercício contínuo de indivíduos e equipes na antecipação e intervenção de potenciais problemas, já que as referências adotadas num planejamento está subordinada à teoria das probabilidades e essas padecem da falta de exatidão.

Os projetos passam por ambientes instáveis com frequentes mudanças, trazendo grandes desafios na tomada de decisões durante seu progresso. Esses ambientes são caracterizados por elementos conhecidos como VUCA.

VUCA é um acrônimo utilizado originalmente no vocabulário militar para representar as palavras Volatility (volatilidade), Uncertainty (incerteza), Complexity (complexidade) e Ambiguity (ambiguidade), referentes às condições gerais e situações intrínsecas em determinado ambiente. Estar ciente dessas condições estimula o uso da competência analítica e do julgamento no que se refere à identificação e ao tratamento de problemas.

Uma definição mais detalhada desse acrônimo traz os seguintes significados:

• Volatility (volatilidade): A natureza, a velocidade, o volume e a magnitude da mudança que não se encontra num padrão previsível. A volatilidade é turbulência, um fenômeno que está sujeito a acontecer com mais frequência atualmente.

• Uncertainty (Incerteza): A falta de previsibilidade em assuntos e acontecimentos.

• Complexity (Complexidade): As inúmeras causas difíceis de compreender e os fatores atenuantes (tanto dentro como fora da organização) que estão envolvidos num problema.

• Ambiguity (ambiguidade): A falta de clareza sobre o significado de um acontecimento. Pode significar também as causas e razões por trás das coisas que estão para acontecer, que são difíceis e pouco claras de determinar.

Saber da existência dos critérios do ambiente VUCA contribui na estruturação de processos de gestão dos seguintes aspectos:

• Antecipar as questões que modelam as condições;

• Compreender as consequências de questões e ações;

• Avaliar a interdependência de variáveis;

• Preparar-se para realidades e desafios alternativos;

• Interpretar e abordar oportunidades relevantes;

O ambiente VUCA pode trazer impacto (s) a algum dos objetivos dos projetos, pois está suscetível a três potenciais fontes problemas: “Jeopardize”, “Risk” e “Chaos”.

1ª Fonte > Jeopardize > Por em Risco > Fato > Sob Domínio > Influência Interna > Previsível > Passado (lições)

2ª Fonte > Risk > Ser um risco > Incerteza > Não Domínio > Influência Externa > Previsível > Futuro (prognostico)

3ª Fonte > Chaos > Acaso > Incerteza > Não Domínio > Acidental > Não previsível > Presente (diagnostico).

A primeira fonte foi batizada de “Jeopardize” – palavra que vem do inglês e significa “pôr em risco”. No ambiente de projetos essa é a principal fonte de problemas e inclui os fatos previsíveis (de origem interna à organização) que deveriam estar sob o domínio dos tomadores de decisão em projetos. O volume de problemas relacionados a essa fonte é inversamente proporcional ao nível de consciência dos gestores e das equipes no que diz respeito à influência e ao impacto da eficiência operacional da organização para o projeto.

Uma das responsabilidades básicas de um gestor de projetos, por vezes negligenciada, é conhecer diretamente (ou através de especialistas) a maturidade da organização que ele usará como base de sustentação para seu projeto.

Conhecer essa maturidade em nível estratégico é saber como funciona o apoio, a cultura, a estrutura, o alinhamento de objetivos e a arena política da organização, em nível tático isso significa ter ciência da maturidade das equipes e maturidade dos processos internos.

Agir e obter resultados positivos junto aos problemas da categoria Jeopardize depende mais das atitudes e postura das autoridades do projeto e da organização do que do conhecimento e da experiência técnica inerentes à unicidade do projeto. Essa atitude inclui agir antes de o problema ser deflagrado no projeto e também, caso deflagrado, possuir planos cuidadosamente estabelecidos para as atividades e entregas críticas do projeto.

A qualidade do planejamento de um projeto depende em grande parte de identificar processos com problemas recorrentes conhecidos pela organização, porém ainda não tratados devido à ausência ou procrastinação da tomada de decisões das autoridades da organização ou do projeto, colocando em risco o sucesso e os benefícios estimados na preposição do projeto.

A segunda fonte foi batizada de “Risk”, ou seja, um risco legitimo proveniente de eventos ou condições incertas imaginadas ou estimadas que estão no futuro. O gerenciamento de riscos em projetos, aplicado com maestria, tem por objetivo planejar e executar ações preventivas no intuito de eliminar ou minimizar potenciais problemas. A grande diferença entre Jeoparize e o Risk é que no primeiro caso os problemas são factuais e no segundo são imaginados, ou seja, não podem ser vivenciados diretamente antes de acontecer. Apesar do Risk não estar no domínio direto dos gestores de projetos, por sofrer influencias externas, estes podem ser previstos quando a visão comum do projeto é construída e a identificação de fontes ou categorias de riscos é adequadamente estabelecidade junto aos stakeholders.

Na terceira fonte, batizada de “Chaos”, o foco é agir o mais rápido possível para minimizar as “perdas”. Ela difere das fontes Jeopardize e Risk, em que os problemas podem ser eliminados, minimizados ou contornados. Nesse contexto é natural a ausência antecipada de estratégia. As ações junto a esses problemas são normalmente iniciadas como uma resposta a uma crise ou como evento inesperado. Logo, os problemas nesse ambiente precisam ser gerenciados diferentemente das outras fontes, pois não há tempo para um planejamento detalhado. O improviso entra em cena e o trabalho é executado continuamente com interações sem parada e tomada de decisões contínuas. Para agir nessas situações é necessário que as autoridades do projeto tenham consciência de que o gestor de projetos e/ou especialistas devem ter total autonomia em decisões e que assumam a alta probabilidade de os custos finais dessa empreitada serem bastante elevados.

Essa fonte está ligada à “teoria do caos”, em que uma pequena mudança no início de um evento qualquer pode trazer consequências enormes e absolutamente desconhecidas no futuro.

Segue abaixo um Checklist – Avaliação de potenciais problemas para o projeto.

Clique aqui


Compartilhe nas redes sociais:

INTRODUÇÃO

Em ambiente dinâmicos e em constante transformação, ganhar e manter a competitividade são dois importantes objetivos organizacionais. Nesse contexto as empresas buscam continuamente desenvolver novos produtos e serviços, tentando identificar em suas cadeias de operações novas formas de agregar valor para o cliente.

Mas, afinal, o que é valor? Ele pode ser definido como o quanto o cliente estaria disposto a desembolsar monetariamente pelo benefício gerado na aquisição de um determinado produto ou serviço. Resumidamente, é a relação entre o benefício e o seu respectivo custo. Essa é uma relação bastante interessante, mostrando que o objetivo de criar ou aumentar o valor consiste em maximizar o benefício oferecido ou reduzir seu custo de produção. Entende-se por produção o processo da aquisição da matéria-prima até a entrega do produto ou serviço.

No cálculo do valor, a variável custo, que está no denominador. É relativamente simples de se calcular, bastando somar os custos de cada um dos componentes do produto ou serviço. Porém, esse mesmo raciocínio não é tão intuitivo para a variável do numerador quando se quantifica um benefício.

Quanto vale o benefício de cada um dos quatro parafusos que prendem as rodas de um automóvel? Quanto vale o benefício da digitalização e a guarda de um documento? Naturalmente, considera-se o componente do produto ou serviço como base de cálculo para se determinar o custo e consequentemente o seu benefício; porém, será que essa é a forma mais eficiente?

CONCEITO DA FUNÇÃO DE VALOR

Considere, por exemplo, dois modelos de um ventilador doméstico. O primeiro possui mecanismos internos que fazem com que ele se movimente automaticamente, direcionando o vento horizontalmente. No segundo modelo, o aparelho não se movimenta, porém o direcionamento do vento é feito também de forma automática por meio de aletas de direcionamento horizontal.

Percebemos e associamos o benefício à função de direcionamento do vento e não diretamente aos mecanismos ou componentes de cada equipamento. Observa-se que essa função, denominada função de valor, é a mesma para os dois aparelhos. Além disso, desde que o perfil dos clientes seja o mesmo, esse benefício terá o mesmo peso relativo em relação ao total dos benefícios oferecidos pelo ventilador. Porém, como anda modelo está vinculado a mecanismo e componentes distintos, cada qual possuirá um custo e consequentemente valores diferentes.

Considere ainda um terceiro modelo, que possui aletas que se movimentam não somente para os lados, mas verticalmente. Nesse caso o benefício oferecido para a função de valor será maior e, devido aos novos mecanismos, o custo também será diferente. Para que o valor da função direcionar vento também seja maior, é necessário que esse novo custo agregado seja proporcionalmente menor que seu respectivo benefício.

Função de valor: quantificação do benefício

Um desafio importante está na quantificação do benefício. Calcular o valor absoluto de um benefício é uma tarefa bastante complexa; então se adota o conceito do benefício relativo, em que cada função de valor do produto ou serviço terá seu benefício avaliado em relação ao benefício total oferecido pelo produto ou serviço sob a forma de um percentual. Dessa forma, não é necessário quantificar monetariamente o benefício de forma absoluta.

Função de valor: quantificação do custo

Inicialmente os custos dos componentes e subcomponentes são calculados e, da mesma forma, seus percentuais relativos. Posteriormente, esses percentuais são absorvidos pelas funções de valor fazendo com que cada uma delas possua um custo. Um componente pode estar relacionado a mais de uma função de valor e uma função pode estar associada a mais de um componente.

Função de valor: identificação de oportunidades

Como aumentar o valor da função de valor identificando oportunidades de redução de custo ou aumento de benefício?

Na visão de um determinado perfil de cliente, considere um automóvel cuja função de valor frear o veículo, associada ao componente sistema de freios, seja tão importante quanto a função de valor movimentar o veículo que está associada aos componentes transmissão, motor e rodas. Considere que cada uma dessas funções de valor seja responsável cada qual por 25% (*) do valor benefício total.

Agora suponha que a função de movimentar o veículo (associada aos componentes transmissão, motor e rodas) seja responsável por 50% (*) do custo total de produção do automóvel e a função parar o veículo (associada ao componente sistema de freios) em torno de 10% (*).

Dessa forma, considere o valor da função movimentar o veículo como 25% / 50%, ou seja, o custo relativo da função é o dobro do seu benefício relativo. Em contrapartida, no caso da função parar o veículo a relação é de 25% / 10%, ou seja, o custo relativo é inferior ao seu benefício relativo. O problema ocorre quando na função de valor o custo relativo é superior ao respectivo benefício relativo ofertado. (*) valores fictícios.

A TÉCNICA

A técnica de engenharia e análise de valor tem o objetivo de identificar oportunidades de aumentar o valor das funções de produtos ou serviços. Foi desenvolvida em 1947 por Lawrence D. Miles da General Eletric Company cujo objetivo era a identificação de componentes de produtos visando à redução de seus custos sem afetar a qualidade funcional dos mesmos.

Procura identificar as funções de valor dos produtos e processos quantificando seus benefícios e custos relativos retirando o foco de seus componentes. As funções cujo custo relativo está incompatível com o benefício relativo da função são os candidatos alvo para estudos de melhoria. O termo análise de valor é geralmente aplicado para produtos existentes e engenharia do valor para novos produtos.

O diagrama FAST (Function Analysis System Technique) objetiva desdobrar e identificar as funções de valor.



CONCLUSÃO

O objetivo primordial dessa técnica é aumentar o valor do produto ou serviço, de acordo com cada segmento ou perfil do cliente. O desafio está em mudar o paradigma, da visão de componentes para as funções de valor.

Utilizando o exemplo do sistema de freios do automóvel, tem-se a visão da função de valor “parar o veículo”. Nesse caso, abre-se um leque para os engenheiros repensarem na função “parar o veículo” que não necessariamente utilizaria da mesma forma o sistema atual de freios, remetendo a um processo puro de inovação. Nesse caso, o valor deve ser mantido ou melhorado por algum outro mecanismo de parada em que novos componentes poderiam eventualmente surgir para oferecer o mesmo valor da função, porém com um custo inferior.

Finalmente, oportunidades na aplicação dessa técnica podem ser exploradas na área de serviços e de projetos de melhoria, redesenho e reengenharia de processos, em que os componentes como autorizar, transportar, informar, aprovar, revisar, guardar, controlar podem ser revisitados numa visão de função de valor.

 

Compartilhe nas redes sociais:
Pagina 1 de 2

Mais Lidos

Siga pelo Facebook

Galeria

Novas luzes inteligentes para a iluminação urbana

O QUE OS EXECUTIVOS DEVEM EXIGIR DE SUAS EQUIPES DE PROJETOS

Piauí tem o maior parque de energia solar em operação na América do Sul

Introdução a Duração Agregada

A aposta de Bill Gates (Grupo BEV) em Energia Geotérmica

Os Problemas em Projetos

A Volkswagen vai recompensar os alemães que abandonarem os seus carros mais poluentes

BNDES aprova R$ 6,7 milhões para fazer rede de recarga de carros elétricos

Perovskita, o mineral raro que poderá deixar a internet 1000 vezes mais rápida

© 2019 Engenheiro S/A. Todos os direitos reservados.