Ei vocà sabe dizer n∆o

Ei! Você sabe dizer não?

Peter Berndt de Souza Mello Resumo: Na medida em que vamos desenvolvendo trabalhos técnicos na área de gerenciamento de projetos e somos capazes de coletar informações cada vez mais consistentes para a elaboração de planos e cronogramas adequados, também temos a oportunidade de perceber que grande parte das falhas em projetos é por uma dificuldade das pessoas em estabelecerem limites para os seus trabalhos e – em essência – saber dizer “não” ao cliente, ao colega de trabalho, ao gerente de projeto e demais pessoas envolvidas. Este artigo estabelece um estudo técnico-social em relação ao que esse problema realmente pode significar em projetos e alerta a comunidade à necessidade de desenvolvermos a habilidade de criar limites, estabelecer metas e dizer “sim” ou “não” com consciência. A transformação necessária então alia um clima de rebeldia à necessidade de se evoluir em função das boas práticas e valorizando a análise de riscos em projetos.

1. Identificação do Problema Enquanto a única certeza que temos em projetos é que qualquer planejamento nunca é suficiente, necessitamos capacitar os envolvidos em um projeto a perseguir os melhores resultados possíveis mesmo havendo grande concorrência de objetivos entre aqueles que representam a empresa executora, o cliente, o gerente de projeto, fornecedores e membros de equipe.

Para isso, devemos desenvolver cronogramas consistentes e relacionamentos adequados entre atividades, prazos e custos. Receber informações incompletas, imprecisas e inconsistentes das pessoas envolvidas passa então a representar a maior fonte de risco para o sucesso de projetos.

Aliado ao fato de que o projeto sofre de uma natureza “progressiva” onde não sabemos exatamente tudo o que deve ser o “trabalho e somente o trabalho acordado” até mesmo no último dia de projeto, temos ainda a intrínseca dificuldade das pessoas em “dizer não” as pessoas ao seu redor, em especial dentro de uma estrutura hierárquica (do funcionário em direção ao “chefe”).

Dizer “não” neste contexto não é apenas se negar a realizar uma determinada ação, mas também se negar a: - Aceitar a organização de uma rede de atividades inconsistentes; - Aceitar a imposição de datas e durações indevidas; - Aceitar a limitação de recursos em função de uma economia questionável; - Experimentar um ambiente de projetos desprovido de informações adequadas; - Se comprometer com níveis de incerteza não identificados.

E com isso: - Desenvolver sua capacidade de liderança e influência sobre os stakeholders; - Planejar com maior cuidado e níveis de detalhe todas as etapas de projeto; 1

- Envolver e motivar os envolvidos em função de resultados realistas.

2. Revoluir (Rebeldia e Evolução) Na década de 90 o PMBOK® ganhou mercado - em especial - por criar um vocabulário comum que poderia ser discutido e entendido por gerentes de projeto e membros de equipe em todo o mundo. Em pouco tempo, inclusive clientes, fornecedores e patrocinadores de projetos também começaram a utilizar seu vocabulário e seus conceitos.

Agora já reconhecemos uma profissão chamada “gerente de projetos” e entendemos que um projeto deve atender uma série de requisitos nas áreas de gerenciamento do escopo, do prazo, dos custos, da qualidade, de recursos humanos, comunicação, riscos e aquisições, todos estes relacionados por um conjunto de processos voltados ao gerenciamento da integração.

Ainda assim, mesmo membros de equipe, clientes e gerentes identificando boas práticas que não vem sendo empregadas em seus projetos, falta um impulso complementar em diversas situações onde trazemos todos os envolvidos a trabalharem com um mesmo objetivo: conduzir um projeto dentro da qualidade acordada.

Na construção deste espírito, através de listas de discussão, grupos de alunos em diversos cursos e membros de projetos, foi possível instituir uma espécie de “grito de guerra” com o objetivo de nos manter focados no sucesso do projeto, buscando resolver as diferenças naturais entre as expectativas de todos os envolvidos.

Nasceu assim “Revoluir” – um mix de “rebeldia” para “evoluir” em projetos. “Revoluir” é um grito de guerra, é uma palavra de ordem entre membros de uma equipe, é um mecanismo de confronto sadio entre gerentes de projeto, equipes e demais envolvidos.

No contexto de uma organização social, “Revoluir” vem sendo apenas um mecanismo de extrapolar o sentimento de fazer bem. De buscar a aplicação das boas práticas doa em quem doer, desde que atendendo aos requisitos para o qual o projeto foi concebido sem abrir mão da ética e a responsabilidade profissional.

A existência de uma palavra para simbolizar uma busca pela evolução ainda que provocada por um tom de rebeldia tem se mostrado eficiente em dar forças àqueles profissionais que precisam dizer “não” aos seus líderes, chefes, coordenadores, gerentes e clientes.

3. Reconhecendo a importância do ACASO A essência de se dizer “não” está em reconhecer que a incerteza e o acaso imperam em qualquer projeto. Constrói-se assim uma transformação do “Triângulo de Ferro” e a trilogia do custo, do prazo e do escopo não pode mais ser enxergada sem uma análise de riscos (Fig.1)

2

Fig.1 – A transformação do “triângulo de ferro” pelo reconhecimento da incerteza Quando desenvolvemos um cronograma baseado em uma única estimativa estamos agindo de forma extremamente otimista mesmo quando aplicamos aquilo que chamamos de “mais provável”. O que de fato ocorre é que acreditamos que aquela informação incutida em nosso diagrama de redes é correta e que o resto é apenas o acaso.

Em “revoluir”, vamos lembrar-nos de outras coisas importantes do PMBOK como: •

Aplicação do PERT/CPM;

•

Monte Carlo;

•

PDCA;

•

ISHIKAWA;

•

Estimativas em três pontos;

•

...

Nosso grande desafio então - em nosso dia-a-dia de projetos - é o de buscar a cumplicidade de todos os envolvidos para realizarmos uma aplicação efetiva do “conjunto de conhecimentos” que deveriam moldar nossos projetos.

Nesta visão, entregar um cronograma de projeto contendo prazos otimistas, pessimistas e prováveis parece absurdo em muitos casos não só para o cliente, mas para a organização que o executa, o próprio gerente de projeto e membros de sua equipe.

Talvez esteja na essência do brasileiro contar com o “jeitinho” ou deixar a busca pela solução de um problema somente em sua evidência. Não importa se é uma questão cultural particular nossa ou uma lei universal, gerentes de projeto não podem se acomodar com este princípio.

4. Aprendendo a dizer “não” Exemplos práticos de casos reais em sala de aula vêm sendo um mecanismo eficaz para preparar gerentes de projeto a dizer “não”. Em uma destas situações, um gerente de projeto com apenas algumas semanas em uma empresa recebe uma ordem de serviço para o desenvolvimento de um software que deveria ser realizado em 60 dias, com escopo e custo já definidos.

Ciente de que qualquer projeto deve ter metas estabelecidas dentro de margens, com alguma flexibilidade em uma das três áreas (ou alteração do escopo, do prazo ou do custo), o GP iniciou uma análise de viabilidade em relação ao software e recebeu o aviso do gerente de fábrica de que o projeto deveria ser feito exatamente como descrito na ordem de serviço. A solução foi reunir técnicos em diferentes áreas e levantar um cronograma inicial com prazos mínimos e máximos para cada tipo de atividade e um conjunto de recursos compatível com o volume de trabalho previsto. Diante da impossibilidade de – em apenas 60 dias – ter condições para detalhar, distribuir, desenvolver e testar componentes de software que necessitariam de um pico de cerca de 10 desenvolvedores ainda não disponíveis na empresa, o GP levou o caso à diretoria, ignorando a limitação imposta pelo gerente de fábrica e solicitando uma visita ao cliente para redefinir prioridades de projeto. É evidente que a situação não é confortável visto que com pouco tempo de casa o gerente de projeto necessita escalonar um problema para garantir uma execução adequada do seu projeto. Ainda assim, melhor gerar o conflito no início do projeto a não ter uma oportunidade para cumprir com seus objetivos principais: concluir o projeto e atender seu cliente.

3

Em conjunto com a diretoria e o gerente de fábrica, o gerente de projeto consegue uma visita ao cliente solicitante e se instrumenta com cronogramas alternativos, análises de cenários otimistas e pessimistas, registros históricos de tempo de mobilização e outras informações para negociar com o cliente alguma alteração nos objetivos do projeto.

Feita a reunião, o gerente de projeto obtém um acréscimo de 50% em verbas de projeto e o tempo triplicado. O cliente entende a necessidade de se manter uma equipe pequena de projeto e focada na qualidade do desenvolvimento e todos conseguem vantagens da reunião provocada pela “rebeldia” do gerente de projetos: A empresa terá um faturamento maior, o cliente melhor qualidade de produto e cronograma compatível com a realidade e o gerente de projeto as condições necessárias para cumprir com seus objetivos.

A natureza do trabalho do gerente de projeto é de conflitos. Viverá sempre entre stakeholders com objetivos concorrentes e necessidades particulares e o GP precisa estabelecer o balanço entre aquilo que irá garantir o lucro ao seu patrocinador, as condições de trabalho de sua equipe e a qualidade solicitada pelo cliente. Por outro lado, o Gerente de Projeto que estiver capacitado a trazer argumentos adequados a cada tipo de envolvido e trabalhar em função de situações “ganha-ganha” logo terá condições de cada vez mais estabelecer limites diante de cada envolvido, independente de seu nível hierárquico.

Isso significa que na medida em que for evoluindo com projetos que se aproximam de suas metas, mais e mais irá ter o respeito e confiança de seus pares, de sua equipe, de seus clientes e patrocinadores para efetivamente cumprir com seus compromissos. Assim, paradoxalmente, quanto mais capaz for o GP de dizer “não” as pessoas com quem se relaciona em um projeto, mais capaz será de dizer “sim” aos objetivos do projeto!

5. Conclusões A trajetória para o sucesso de qualquer projeto passa por um planejamento adequado de suas ações e um envolvimento freqüente com os envolvidos para estabelecer sinergia entre os objetivos particulares em função de uma meta comum.

Isso significa evoluir em relação às práticas e técnicas – entre elas o detalhamento de pacotes de trabalho em uma EAP com a constituição de cronogramas baseado em restrições e não somente a aplicação de CPM; A identificação, análise e resposta adequada aos riscos de projeto; o planejamento e execução de uma boa comunicação com todos os envolvidos em um projeto; um adequado sistema de coleta e resposta a informações de projetos entre outros.

No entanto, o conjunto de técnicas, ferramentas e habilidades deve ser direcionado ao desenvolvimento de uma liderança em projeto que permita manter a equipe motivada, o cliente seguro dos resultados do projeto e o patrocinador ciente das oportunidades e problemas inerentes ao projeto. Não se pode alcançar esta tão desejada “liderança” apenas com sorrisos e compromissos com todos os envolvidos sem uma análise consistente dos conflitos existentes e o desenvolvimento de uma rotina de se estabelecer limites tanto ao cliente, como o patrocinador ou membros de equipe. Estabelecer limites é – em última instância – saber o momento apropriado de se dizer “não”.

Gerentes de projeto que não sejam capazes de dar fundamentação técnica a seus argumentos para a adequação de custos e prazos ao escopo definido terão maior dificuldade em desenvolver uma liderança efetiva em projetos. Em outra perspectiva, gerentes de projeto envolvidos apenas na manutenção de relacionamentos – políticos, afetivos ou comerciais – sem a preocupação de estabelecer limites razoáveis às expectativas dos envolvidos, também não irão alcançar os seus objetivos.

4

Pecando pelo clichê, o gerente de projetos deve se desenvolver considerando o gerenciamento de projetos como ciência e arte, adequando sua capacitação técnica às habilidades de relacionamento interpessoal.

Referências Bibliográficas Archibald, Russell D. 2003. Managing High-Technology Programs and Projects, 3rd Edition. NY: John Wiley & Sons, Inc. Goldratt, E. M. 1997. Critical Chain. Great Barrington, MA: North River Press.

Mello, Peter. “Revoluindo: Rebele-se para Evoluir”. Texto on-line publicado em http://www.revoluting.com disponível em 01/07/2008.

Mello,

Peter

“Tratando

os Atrasos”.

Texto http://www.revoluting.com disponível em 01/07/2008.

on-line

publicado

em

Mello, Peter “Cronogramas Realistas”. Texto on-line publicado em http://www.revoluting.com disponível em 01/07/2008.

PMI® PMBOK® Guide: A Guide to the Project Management Body of Knowledge.

Newtown, PA: Project Management Institute 2004.

5