5jun, 2013

Controladoria aplicada na gestão de estoques e custos

Com o mundo cada vez mais globalizado os clientes estão cada vez mais exigentes e se faz necessário que os produtos tenham custos cada vez mais competitivos, sejam entregues cada vez mais rapidamente aos clientes e cada vez mais tenha um maior valor agregado.

È importante conhecermos informações que nos permitam responder a questões como: Qual é o nível ótimo de estoque? Qual o do nível de estoque que devo manter para atender os meus clientes? Quais centros de distribuição que devem ser utilizados?

Perguntas como estas devem ser respondidas com segurança e informações corretas. Para a área de estoques podemos utilizar o conceito dos 7C’s (certos) surgido dentro da logística e tem como objetivo maior integrar os processos de negociação e comercialização que visam a atender os clientes, ou seja, o conceito diz que devemos: “Assegurar a disponibilidade do produto certo, na quantidade certa, e na condição certa, no lugar certo, no momento certo, para o cliente certo, ao custo certo”.

O controle dos custos é outro grande segredo da eficiência de uma empresa, pois os custos são medidas monetárias dos sacrifícios despendidos para se atingir um objetivo, sendo assim a coleta destes é de suma importância para os processos de decisão e planejamento da empresa.

Dentro dessa perspectiva podemos destacar quatro situações em que a coleta de dados é muito importante perguntas como: O que vamos fabricar? Quanto irá custar? E por quanto vamos vender?

Essas perguntas são muito importantes para o planejamento e controle de custos, a análise entre real x orçado, procurando sempre ajustar o custo real ao custo orçado, permite mensurar os resultados desses ajustes e assim decidir o que se deve produzir.

Esses processos decisórios requerem da área de Controladoria a elaboração de um Sistema de Informação Gerencial ágil, flexível e compatível para a gestão de custos e estoques das empresas as características destes sistemas é dar suporte às funções de planejamento, controle e organização de uma empresa, fornecendo informações seguras e em tempo certo para tomada de decisão. O sistema de informação gerencial é representado pelo conjunto de subsistemas, visualizados de forma integrada e capaz de gerar informações necessárias ao processo decisório.

Como vimos nos produtos estão contidas parcelas de custos que irão ser estocados para posterior venda, esses custos de produção juntamente com as despesas de manutenção e distribuição dos estoques se não forem bem calculados e administrados, os produtos irão carregar a ineficiência desses processos, e como consequência do não planejamento e controle desses, a empresa não alcançara o seu objetivo maior: o lucro nas operações.

Pedro Paulo Galindo Morales é Graduado em Gestão de Sistemas Produtivos, possui especialização em Controladoria e trabalha na área de Gestão Orçamentária de uma empresa multinacional de Distribuição de Energia Elétrica.

Blog: www.falandodegestao.wordpress.com
E-Mail: [email protected]

4jun, 2013

Nivelamento de Recursos

O PMBOK (2009) prevê como insumo para montagem do cronograma:
– WBS
– Dicionário da WBS
– Quantidade de Recursos
– Estimativa das Atividades
– Diagrama de Rede

O terceiro item, quantidade de recursos, é calculado por muitos gerentes de projeto apenas de maneira isolada atividade por atividade, e não em uma abstração macro do projeto como um todo.

Esse fato acarreta a super-alocação de recursos em determinados períodos do projeto. Quando o gerente de projeto olha apenas para a atividade, passa despercebida a quantidade de recursos que aquelas atividades juntas estão demandando, principalmente quando essas estão sendo executadas em paralelo. Em uma análise de alto nível no cronograma, pode-se chegar à conclusão que, em determinado período, o projeto não possui tantos recursos como planejado, nem verba suficiente para tantas horas extras como previsto.

Na análise simplista de atividade por atividade, essas conclusões nunca seriam obtidas.
Então há duas possibilidades:
– Contratar mais recursos para as demandas nos períodos críticos
ou
– Nivelar os recursos
O Nivelamento de Recursos, em inglês chamado de Resource Leveling, é uma técnica que evita a super-alocação dos mesmos. Recursos são retirados de atividades não criticas e alocados em atividades criticas. Porém, apesar do nivelamento garantir que os recursos não estejam super-estimados, evitando picos, o método normalmente aumenta o prazo do projeto. Sendo assim, análises de custos e prazos devem ser feitas antes do nivelamento e verificadas novamente após a aplicação do método.
Como exemplo, podemos citar um caso do livro “Certificação PMP, de Armando Monteiro, Segunda-Edição – Editora Brasport”:
Antes do nivelamento:
1) Primeira Semana – 2 recursos
2) Segunda Semana – 4 recursos
3) Terceira Semana – 8 recursos
4) Quarta Semana – 2 recursos
Após o nivelamento:
1) Primeira Semana – 2 recursos
2) Segunda Semana – 4 recursos
3) Terceira Semana – 4 recursos
4) Quarta Semana – 4 recursos
5) Quinta Semana – 2 recursos
Percebe-se que o projeto nivelou os recursos, mas o prazo foi aumentado em uma semana. Supondo que o projeto disponha apenas de 4 recursos trabalhando juntos, o nivelamento resolveria o problema de ter 8 recursos na terceira semana, mas o prazo seria afetado.
Muitos gerentes de projeto, erroneamente, fazem o nivelamento já na fase de execução, quando percebem que não possuem tantos recursos como planejado no cronograma. E após a aplicação do método, chegam à conclusão que precisam renegociar o prazo com o cliente, pois os picos de super-alocação foram pulverizados e assim o tempo estendido.
O Nivelamento de Recursos é muito pouco utilizado em softwares de gestão de projetos, mas a aplicação existe nas ferramentas. O Microsoft Project, por exemplo, possui a opção da ação de nivelamento. Em um segundo o cronograma pode ser nivelado.
A técnica aborda situações em que recursos necessários ou compartilhados estão disponíveis somente em determinados períodos ou em quantidades limitadas. Sendo essa a realidade de praticamente todos os projetos, o Nivelamento de Recursos se torna fundamental para um bom plano de gerenciamento de tempo.

Clay Susini é Gerente de Projetos, Consultor em TI e na Área Financeira
[email protected]

4jun, 2013

Diferenciando Premissas de Restrições

Quando o assunto é gerenciamento de projetos, constantemente observo pessoas confundirem premissas com restrições e vice e versa.

A confusão entre essas palavras ocorre cedo, logo no processo de iniciação, em um dos primeiros documentos do projeto: o Termo de Abertura (Project Charter). Esse documento, utilizado para o Sponsor (patrocinador) aprovar o início do projeto, requer que sejam expostas as premissas e as restrições. Apesar de cometido no começo do projeto, o erro de conceito é percebido comumente apenas no processo de execução, onde eventuais mudanças já requerem alto grau de esforço e validação política junto ao Sponsor.

Mas afinal: Qual a diferença entre premissas e restrições?

Basicamente premissas são hipóteses e restrições são deveres. Porém, essa definição não basta para apresentar claramente a diferença entre os dois termos. A chave da questão está na pergunta: “Quem executa o trabalho está no ambiente externo ou interno ao projeto?”.

Premissas são suposições dadas como certas sobre o ambiente externo ao projeto. Sobre elas é baseado o plano e a promessa de tempo e custo.

Podemos resumir a afirmação acima na equação:

Premissas = Suposições + Ambiente externo ao Projeto

Já restrições são limitações impostas internamente ou externamente ao trabalho executado pela equipe de projeto.

E a equação para a afirmação acima seria:

Restrição = Limitações + Ambiente Interno ou Externo ao Projeto + Trabalho Executado pela Equipe de Projeto

Para exemplificar, segue um organograma padrão, pertinente a quase todos os tipos de projeto:

{gallery}GP{/gallery}

Com base na visão deste organograma, vamos supor a criação de um projeto referente a uma luxuosa e grandiosa festa de casamento ao ar livre em um sítio no período da manhã. E na Declaração de Escopo do Projeto há a seguinte descrição:

A luz do sol será refletida nos prismas colocados à margem do lago situado atrás da capela, produzindo um arco-íris.
Para que esta ação ocorra, não há dependência única de trabalho executado pela equipe do projeto, mas sim de um fator externo ao controle do projeto: o clima. Se não houver sol, não haverá luz refletida nos prismas e consequentemente não haverá arco-íris. Conclui-se que se trata de uma suposição dada como certa referente ao fator clima que está externo ao controle do projeto. Sendo assim, trata-se de uma premissa. Essa premissa poderia ser declarada da seguinte forma no Termo de Início do projeto:

Haverá sol pela manhã incidindo no lago situado por de trás da capela.

Uma premissa nunca possuirá um termo de obrigatoriedade como a palavra “deverá”. Seria errado reescrever a frase acima da seguinte forma: “Deverá haver sol pela manhã incidindo no lado situado por de trás da capela”. Não é possível obrigar uma premissa a ocorrer, pois ela não está sob o controle do projeto, mas apenas sob monitoramento, consequentemente, não se pode impor a palavra “deverá”.

O fato de não escrever palavras que transcendam o sentido de obrigação em premissas pode parecer capricho, mas não é. Utilizar termos desse tipo pode ser um termômetro para saber se o que está sendo escrito é uma premissa ou uma restrição. Se realmente houver necessidade de inserir, por exemplo, um “deverá” na frase, este pode ser um indício de que a afirmação não é uma premissa, mas uma restrição.

Caso seja realmente obrigatório que uma afirmação aconteça, a atividade responsável para que esta afirmação ocorra deve estar mapeada na Declaração de Escopo do Projeto e incluída na WBS/EAP (Work Breakdown Structure ou Estrutura Analítica de Projeto), para então poder se “candidatar” a restrição. Reiterando: restrições são limitações impostas internamente ou externamente ao trabalho executado pela equipe de projeto. Quando um projeto, por exemplo, é feito sob contrato, as cláusulas contratuais geralmente serão restrições.

Mas continuando com o exemplo do projeto da festa de casamento, uma restrição poderia ser “Todos os garçons devem falar inglês”. Esse item pode totalmente ser atendido apenas com a o trabalho da equipe do projeto através de uma atividade como “Recrutamento e Seleção”, que deve estar mapeada na WBS e descrita na Declaração de Escopo.

E ainda citando o fator clima, caso o projeto incluísse a procura por um local para realização da festa, uma restrição poderia ser “O evento deverá ocorrer em um sítio no Estado de São Paulo, no município que apresente o menor índice de chuva no mês de maio dos últimos 5 anos”. Esta ação pode ser sanada através de uma atividade de pesquisa completamente passível de realização pela equipe do projeto. Não está sendo exigido que haja sol, mas apenas que o evento seja realizado em um local que historicamente possua a menor incidência de chuva no mês desejado.

Convém ressaltar que tanto Premissas como Restrições, além de serem expostas no Termo de Início, também devem ser descritas na Declaração de Escopo do Projeto ou em um documento específico. A diferença é que o trabalho responsável por satisfazer uma Premissa não existe na Declaração de Escopo, nem na WBS, pois não se trata de uma atividade que está sob controle da equipe do projeto, ou seja, não há trabalho dentro do projeto. Ao contrário, uma atividade responsável por atender uma Restrição deve estar na Declaração de Escopo e na WBS, pois é um trabalho da equipe do projeto.

Clay Susini Aquino Junior possui MBA em Gerenciamento de Projetos pela Fundação Getúlio Vargas e é Bacharel em Sistemas de Informação com Ênfase em Planejamento Estratégico pela Universidade Presbiteriana Mackenzie. É membro do PMI (Project Management Institute) e ministra palestras e aulas sobre Gerenciamento de Projetos, Metodologias de Projetos de Desenvolvimento de Software e Gestão Financeira.

Contato: [email protected]

4jun, 2013

Gerenciando por tendências: Matemática, estatística e conhecimento

Muito se fala em gerenciamento por tendências, mas o que é isso? Vou tentar dar uma resposta bem direta e resumida. Gerenciar por projetos nada mais é do que o uso objetivo e simultâneo de matemática, estatística e conhecimento do ambiente passado e presente do projeto.

Não entrarei no mérito das “fórmulas”, para isso proponho que procurem algo sobre “EVM” (Earned Value Management ou Gerenciamento de Valor Agregado). A parte matemática e estatística do gerenciamento por tendências, nada mais é do que a solução de algumas contas simples (como diria um ex-professor meu, conta de padeiro!) e a análise de métricas em determinada fase do projeto, ou seja, não exige nenhum conhecimento especial. Um bom usuário de excel é capaz de fazê-lo. Então, qual o grande segredo? A resposta é simples: Conhecer o projeto, conhecer o produto do projeto e as circunstâncias na qual ele foi, está sendo e será executado. Por exemplo:

Preciso entregar 10 plantas em 20 dias, faço uma previsão média de 2 dias para executar cada uma delas. Depois de 10 dias descubro que ao invés de 5, conclui apenas 3. Fazendo uma análise matemática afirmo com absoluta certeza que o projeto está atrasado! Mas está? Quais foram as condições que levaram a entrega de 3 plantas e não 5? Essas condições se repetirão? É possível que eu tenha executado as 3 plantas de maior complexidade e agora as outras 7 sejam concluídas nos próximos 10 dias? Após analisar todo o cenário, posso afirmar se o projeto está ou não realmente atrasado ou adiantado.

O grande erro, já observei isso não uma ou duas vezes, mas várias, é basear seu relatório de andamento e desempenho apenas em números, contas. Reconheço que muitas vezes as alta administração não tem tempo para relatórios detalhados, mas essas observações são muito importantes, ou estaremos passando posições erradas e que poderão comprometer completamente o projeto, e pior, quando pode não haver mais “remédio” (à não ser atualizar o curriculum).

Gerenciar por tendências não é adivinhar o futuro, mas sim, se aproximar da realidade, acompanhando todo período de duração do projeto.

4jun, 2013

É possível avaliar as pessoas segundo Maslow?

Depois de identificar alguns problemas de produtividade e de qualidade no trabalho, passei o último mês fazendo um exercício mental para avaliação de alguns colaboradores. Basicamente, procurei associar a postura de cada um à “Teoria de Maslow”.

Abraham Maslow propõe que as necessidades humanas estão agrupadas em cinco categorias ordenadas hierarquicamente, à saber:

1) Necessidades fisiológicas: Pessoas precisam ter suas necessidades básicas atendidas, como fome, sede, calor, frio e etc.

2) Necessidades de segurança: Pessoas devem se sentir seguras, com relação a segurança física, residência e etc.

3) Necessidade social:Pessoas possuem necessidade de se sentirem unidas a outras pessoas, de fazer parte de um grupo;

4) Necessidade de estima: pessoas tem necessidade de serem bem consideradas por outras pessoas como significativas, de serem prestigiadas;

5) Necessidade de auto-realização: Pessoas tem necessidade de serem tuo o que são capazes;

Sabidas as cinco necessidades da “Teoria de Maslow”, segue minha conclusão. Na maioria das pessoas identifiquei, no máximo, o desejo de preenchimento da terceira necessidade (o que é diferente de estarem transitoriamente neste estágio) ,ou seja, querem apenas fazer parte de um grupo, o que limita suas ações ao mesmo nível das ações do grupo. Se o grupo estiver na média, elas também estarão na média, o que nivela por baixo a qualidade do trabalho. Portanto, embora sejam pessoas com as quais temos maior facilidade de relacionamento (pelo próprio desejo de fazer parte do grupo), são pessoas, em geral, acomodadas e de baixa ou média produtividade.

Identifiquei poucas pessoas nos estágios 4 e 5. Não coincidentemente, boa parte delas são pessoas de relacionamento um pouco mais difícil, já que são pessoas mais questionadoras, vaidosas e seguras de suas opiniões, porém, com um nível de produtividade alto. Pois bem, sempre ouvi que podemos “moldar” as características técnicas, mas não o perfil das pessoas, ou seja, posso ensinar às pessoas o trabalho a ser feito, mas não mudar seu comportamento, qual dos grupos é mais interessante?

Não sou especialista em gestão de pessoas, mas para os especialistas ficam as discussões: É possível avaliar as pessoas segundo Maslow? O que é melhor? pessoas produtivas de caráter difícil ou pessoas medianas de fácil relacionamento? E se tivermos em nossa equipe apenas pessoas nos estágios 4 e 5? Deixo no ar. Com a palavra, os especialistas!

4jun, 2013

Gerente de Projetos e Gerente de Ferramentas

Há uma questão que gostaria de levantar. Talvez, o termo nem exista, ou caso exista tenha uma outra conotação, é o “Gerente de Ferramentas”. O que observo que vem acontecendo constantemente é o fato de pessoas que dominam ferramentas de gerenciamento de projetos, como MS-project, Primavera, Crystalball e etc. Estão cada vez mais se denominando (ou sendo denominadas) como coordenadores de projeto, Gerentes de projeto, ou qualquer outra coisa do tipo, já que o nome depende muito da estrutura da empresa. Eu, particularmente chamaria essas pessoas de “Gerente de Ferramentas”.

Seguindo essa linha linha de raciocínio, o que diferencia o Gerente de Projetos (GP) do Gerente de Ferramentas (GF)? Pensemos juntos: Quais são as principais competências que um GP deve ter? Pra mim são, acima de tudo, a capacidade analítica, a visão sistêmica do projeto, a capacidade de tomar decisões rápidas (e certas), e avaliar o impacto que elas terão no futuro, a capacidade de negociar e influenciar pessoas.

Estou partindo da premissa que “GF” são pessoas que dominam APENAS ferramentas( há, sem dúvidas ”GP’s” que dominam ferramentas, mas não é esse caso.), portanto, se são apenas “usuários” avançados de softwares, podem eles analisar o projeto como um todo? Saber que um projeto não é composto pela soma aritimética de suas atividades, mas sim que existem muitas outras variáveis implícitas? Conseguem negociar recursos, ou responder a questionamentos cruciais sem muito tempo para decidir, e assumir ou argumentar sobre o que sua decisão pode causar? Podem negociar recursos, influenciar pessoas? Talvez, algumas características eles tenham, mas, Que software pensa assim? Que programa tem essas competências?

Muitas pessoas dizem que “programas são burros”, eu discordo disso. Para mim, programas são extremamente obedientes! Eles fazem, na maioria das vezes precisamente o que foram programados pra fazer. O ”GP” não precisa ser especialista em ferramentas, claro que quanto mais souber, melhor. Mas conhecer programas não é uma das competências essenciais do ”GP”, é apenas um valor agregado. Um “GP” pode ser um excelente “GF”, mas a recíproca não é verdadeira, pois no segundo, falta a essência!

O “GP” precisa entender de pessoas, de projetos e de incertezas! Uma equação extremamente complexa e até hoje sem solução matemática. Como software é matemática, nenhum deles resolve essa equação!

Avalie este post

4jun, 2013

O Feedback como ferramenta para lições aprendidas

Todos nós sabemos a dificuldade que enfrentamos para obter um “relatório” de lições aprendidas, afinal, todo mundo sempre acha que ele será, de certa forma, um relatório de desempenho, portanto tendemos a desconsiderar um erro nosso, e apenas citamos erros dos outros (preferencialmente que tenham sido corrigidos por nós). Afinal, quem gosta de errar e ainda fazer “propaganda” dos erros?

O fato é que além da dificuldade de “‘confessarmos” nossos erros, se alia à omissão de um dos mais importantes stakeholders: O cliente!

É uma situação muito conhecida, especialmente entre os profissionais de marketing, que o cliente insatisfeito (principalmente os parcialmente insatisfeitos) não dão feedback sobre sua “má experiência”, ou eles se acostumam com um serviço pior do que o esperado e se adaptam a situação, ou simplesmente nunca mais consomem tal serviço. Pouquíssimos dão ao fornecedor a oportunidade de saber onde erram e corrigir os erros.

Citarei um exemplo prático. Nos últimos 3 anos, participamos de 3 projetos semelhantes para um mesmo cliente. No terceiro deles o novo responsável pela montagem (os dois anteriores tinham outro responsável) reclamou de algumas informações inadequadas na documentação. O “contra-argumento” foi: “Foi feito exatamente assim nos outros dois projetos! Consultando o montador anterior a resposta foi: “Esses erros já existiam, porém, nós corrigimos durante a montagem, e o “projeto” não ficou sabendo!

O que pareceu uma atitude de “boa fé” do montador, acabou gerando problemas posteriores e certamente retrabalho, estouro de prazo e de custo nos projetos seguintes. Portanto, fica claro a extrema importância das lições aprendidas, e do feedback para que sejam registradas. Elas não evitaram os problemas no projeto atual, mas com certeza evitarão problemas semelhantes ou ainda maior no futuro.

4jun, 2013

Até onde decompor?

Sabemos que uma boa WBS (EAP) é um elemento chave para o sucesso do projeto. Através dela, conseguimos controlar todos os itens da tripla restrição (tempo, escopo e custo). Mas até onde devemos decompor?

O objetivo da WBS é decompor os pacotes de trabalho até o nível mais facilmente gerenciável, mas qual é esse nível? Existem algumas regras, alguns autores falam em pacotes que variem em um mínimo de 8 horas e um máximo de 40 horas, outros que defendem a regra de 80 horas e etc. No entanto, na prática, isto depende do porte do projeto e da periodicidade com a qual seu controle será feito.

Cada pacote de trabalho deve possuir uma duração, um responsável, um custo, e uma métrica para medição de qualidade. Por isso, para mim, esta é a melhor forma de limitar a WBS. Façamos, sempre que abrirmos um pacote de trabalho, essas perguntas: Tem um responsável? Tem uma duração (ou posso prevê-la) estimada? Posso calcular o custo disso? Tenho métricas para medir e aceitar? Caso todas as perguntas tenham resposta continuo a decompor, caso contrário, retorno ao nível imediatamente anterior.

Além destas perguntas, verifico também a periodicidade com a qual o controle do projeto é feita, se vou controlar minhas baselines (tempo, custo e escopo) mensalmente, qual o sentido de decompor os pacotes até o nível de horas? Por isso, ressalto, que a WBS não possui tamanho pré-fixado, e sim depende do porte do projeto.

Lembrando sempre, o custo de gerenciar um pacote não pode ser maior que o custo do pacote! Afinal a WBS serve para facilitar o gerenciamento e não para burocratizá-lo!

4jun, 2013

Você dá a atenção necessária aos seus stakeholders?

Você dá a atenção necessária aos seus stakeholders? Uma das tarefas mais importantes (e difícil na mesma proporção), é mapear todas as partes interessadas do projeto. Apenas para que alinhemos a linguagem utilizada, vamos definir como stakeholders, ou partes interessadas, todos aqueles que influenciam ou são influenciados positiva ou negativamente pelo projeto ou resultado dele.

Quando falamos em mapear e rastrear as partes interessadas, não significa apenas identificar quem eles são. Considere que os stakeholders são riscos em potencial! Riscos não são eventos que confirmados, poderão afetar o projeto positiva ou negativamente? Então, viu alguma semelhança entre as definições? Exatamente! Ambos podem influenciar o projeto tanto para o bem quanto para o mal.

Já que trataremos stakeholders como riscos, precisamos também fazer uma análise completa, graduada, com planos de resposta e etc. A maioria das empresas não trata oficialmente o gerenciamento de stakeholder como uma área de conhecimento do gerenciamento de projetos, consideram apenas como “política”, parte do jogo. Mas independente disso, nos gerentes de projeto façamos nossa parte. Há inúmeras formas de rastrear as partes interessadas.

Particularmente acredito em uma bem simples. Divido-a em três etapas:

1) Identificação: Como o nome diz, identifique quem eles são. Faça uma planilha ou agenda ou qualquer forma que achar melhor, (eu uso uma planilha Excel para todas as três etapas) com nome, cargo, atribuições do cargo, e dados de contato em geral (fone, e-mail e etc);

2) Análise: Preocupe-se com as suas expectativas, o que ele espera do projeto, quais requisitos são importantes. (“Ex.: O Presidente da empresa espera que o projeto traga o retorno financeiro, e preocupa-se com requisitos econômicos, legais e técnicos de alto nível”.) Coloque ainda uma escala de graduação com relação à atitude esperada e atitude demonstrada por ele durante o projeto. Essa comparação é importante. Se a atitude demonstrada pelo stakeholder estiver abaixo da esperada para que o projeto seja bem-sucedido, algumas medidas deverão ser tomadas. Identifique quem influencia e por quem é influenciado. É ai que concentraremos os esforços para que haja uma mudança de atitude. Nos que podem influenciá-lo. Identifique também o tipo de poder (formal ou informal) e crie também uma graduação. (Muitas vezes é mais importante interceder em uma pessoa com alto poder informal, do que uma pessoa que tenha um poder reconhecido hierarquicamente, porém baixo.

3) Ação: Finalmente depois de identificar e analisar é hora de agir. Crie planos de ação para interceder nos pontos que lhe pareceram críticos. Defina também o responsável por ele. Ex.: Em um projeto, tínhamos problemas de relacionamento entre o projetista de estruturas metálicas e o responsável técnico pelo projeto de estruturas no cliente. O representante do cliente tinha um poder informal altíssimo e conseguia convencer seus superiores (poder formal) não apenas a não aprovar o projeto (mesmo sem argumento técnico), como também de não liberar a fatura. O plano de ação foi identificar alguém em nosso time que pudesse ser um melhor interlocutor com o representante do cliente. O encontramos uma pessoa com gostos pessoais muito próximos, e perfil profissional mais flexível e substituímos pelo anterior. Resultado: Nossos problemas para aprovação dos projetos acabaram. Tudo bem, nem sempre é tão fácil, muitas vezes o plano de ação é muito mais complexo ou muitas vezes inviável. Mas não dissemos que stakeholders são riscos? Podem facilitar ou afundar um projeto se mal gerenciados? Então, transferimos, mitigamos e no pior dos casos aceitamos.

4jun, 2013

A satisfação sob o ponto de vista do ambiente de projetos

Não foram poucas as vezes que ouvi falar que uma empresa (principalmente de comercio varejista) “faz tudo pela satisfação do cliente”, ou dos profissionais de marketing que “devemos superar a expectativa do cliente”, ou ainda sob uma visão um pouco mais filosófica “satisfação é algo subjetivo”. Mas e sob a perspectiva do ambiente do projetos?

Essas afirmações podem ser verdadeiras dentro dos contextos originais, mas no ambiente de projetos são irreais (para não dizer surreais). Satisfação está ligada à expectativa. O grande problema é que em projetos nem sempre quem paga pelo projeto é quem o compra, o especifica, e tampouco o usuário. Esse é o primeiro grande trabalho do projeto. Ainda antes do planejamento, saber qual dos stakeholders será satisfeito, quem de fato é o seu cliente. Talvez o que muitos considerem como subjetividade (mas na verdade é insanidade) é querer que todos os stakeholders tenham as mesmas expectativas, e que possamos adotar soluções padronizadas para satisfazê-los. Pois é, Não é assim! No mundo real, todos os stakeholders deverão tentar alinhar suas expectativas em torno dos objetivos do projeto, ou até mesmo da estratégia empresarial, alguns serão mais satisfeitos do que outros, uns “abrirão mão” de mais coisas do que outros e assim sucessivamente.

Não há nada de subjetivo na satisfação, pelo contrário, satisfação tem que ser algo extremamente objetivo. Se não o é, é porque não estamos deixando claro os requisitos do projeto e critérios de aceitação. Aliás, requisito é o item mais importante, ao lado das premissas e das restrições, para que o cliente seja satisfeito.

Por exemplo: Quero um projeto para desburocratizar o fluxo de documentos e reduzir os gastos com papel em um departamento.

O objetivo foi compreendido, mas não quantificado. A ausência de requisitos quantificáveis, torna a satisfação subjetiva. O executante do projeto pode deduzir que a retirada de um processo e a economia de 10% nos gastos com papel seja satisfatório, mas para o cliente, deveriam ter sido retirados 8 processos e a economia deveria ser de 50%. Quando o objetivo não é quantificável, as interpretações são diversas, e certamente alguém não sairá contente. Portanto, a forma correta seria: Projeto de desburocratização, que elimine 8 processos no fluxo de documentação e gere uma economia de 50% nos gastos com papel. Assim, todos saberiam onde devem chegar para que haja a satisfação.

Outro fato importante, é que embora objetiva, satisfação é algo mutável e temporal, ou seja, o que me satisfaz hoje, pode não satisfazer amanhã. Em projetos longos, isso nada tem de incomum. Muitas vezes, por uma modificação no mercado, ou outra razão qualquer, os objetivos iniciais do projeto já não serão mais suficientes para satisfazer o cliente, quando encerrar.

Já passei por uma situação onde a variação de preço do produto final que o cliente produzia, e que gerou a necessidade do projeto, modificou completamente os requisitos iniciais e o cliente não se satisfaria com a entrega final. Por isso, além de alinhar as expectativas, é necessário que os requisitos sejam registrados, e que fique claro que representam uma “fotografia” do momento onde o escopo foi fechado. Se houver alterações de escopo, todos os procedimentos de mudança serão seguidos, e uma nova “fotografia” tirada.

Não tente exceder as expectativas. Sabemos da dificuldade que é atender o escopo combinado dentro do prazo, e do custo. Não é segredo que a grande maioria dos projetos não os atende. Além do risco de “estourar” as estimativas, você ainda adiciona o risco de errar nesse “algo mais” e por em risco todo seu projeto. Portanto, não exceda! O cliente já estará muito feliz se você cumprir o que foi acordado, dentro do prazo, e do custo.

Conclusão: Sob a perspectiva do ambiente de projetos, a satisfação é totalmente objetiva. Deve ser alinhada pelos stakeholders, acordada, quantificada e registrada. Seguindo esses passos, certamente, entregaremos exatamente o que foi pedido e todos sairão mais contentes ao fim do projeto.

Category Archives: Guia PMBOK/PMI