Fracasso 2.0

16/12/2009

in Gerenciamento de Projetos

Post image for Fracasso 2.0

Sequência do papo sobre “O Novo Gerente de Projetos“. Segunda parte de um total de três (ou quatro).

Em todas as turmas do FAN, quando mostrando como todos os requisitos devem derivar dos objetivos do negócio, sempre comentei o seguinte: meu currículo apresenta projetos que tiveram problemas com prazos e orçamentos. Alguns maiores, outros nem tanto. Só me sentiria envergonhado se apresentasse ali algum projeto que tivesse falhado na realização dos objetivos do negócio.

A comunidade de gerenciamento de projetos tem demonstrado maior preocupação com o Valor gerado para os negócios. Dentre vários artigos e outros trabalhos distingue-se, por exemplo, “Diferenciando os Alinhamentos Estratégicos de Projetos“, de Ana Helena Moreira e Fabio Medeiros, publicado na MundoPM de Abr/Mai de 2009. Eles demonstram como a Proposição de Valor de uma organização, da qual derivam as estratégias, deve direcionar “o foco e o conteúdo dos elementos do gerenciamento de projetos”. Aliás, o título do editorial da mesma edição, assinado por Zózimo, é “Valor“.

O PMBoK¹ não dá margens para dúvidas quando registra que “projetos são meios para a realização de metas ou objetivos da organização”. Nem quando afirma que o gerente “entrega projetos balanceando requisitos de escopo, prazos, qualidade e custos”. Ele falha, em minha opinião, quando não explicita que tal “balanceamento” deveria ser orientado pelos objetivos do negócio. Na realidade, o grande problema do PMBoK é não fazer refletir em seus processos a devida preocupação com a satisfação das metas e objetivos da organização.

Alinha-se ao PMBoK o Chaos Report, relatório publicado pelo Standish Group desde 1994. Alinha-se? Sim, ao considerar que um projeto *falha* quando atrasa e/ou estoura orçamento e/ou não entrega todo o escopo *planejado*. Ambos os trabalhos ainda apresentam em seu “espírito” uma preocupação exagerada com o plano. Contra desvios são recomendadas “ações corretivas”, o que deixa entender que o plano está sempre correto; Equivocada seria a execução.

Apesar da qualidade aparecer entre itens que precisam ser “balanceados”, tanto PMBoK quanto o Chaos Report nos remetem ao velho “Triângulo de Ferro” do gerenciamento de projetos: Escopo, Prazos e Custo. Esses três itens configuram as principais preocupações de um gerente de projetos. E elas estão explicitamente refletidas nas várias práticas e processos sugeridos não só nos dois trabalhos mas em vários outros que tratam o gerenciamento de projetos.

O primeiro dos 12 princípios do Manifesto Ágil diz que: “Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso”. Valioso no sentido de que o produto entregue realmente representa um meio eficaz para a busca dos objetivos do negócio. Vários métodos, frameworks e práticas derivados do Manifesto Ágil atestam tal preocupação. Mas alguns parecem limitar a percepção de valor à medição do ROI (Retorno sobre o Investimento). É suficiente?

O Novo Triângulo

Um Novo Triângulo para o Gerenciamento de Projetos

Um Novo Triângulo para o Gerenciamento de Projetos

Jim Highsmith, em “Agile Project Management – Second Edition²“, sugere a adoção de um “novo triângulo”, de algo que de fato represente as principais preocupações de um novo gerente ou líder de projetos. Para ele, as três pontas deste novo triângulo são: Valor, Qualidade e Restrições. Segue uma breve explicação sobre cada uma:

  • Valor: representa diretamente a contribuição para a realização dos objetivos do negócio. Quando tratamos de um sistema para uso próprio, avaliamos e valorizamos a eficácia com a qual ele ajudará a empresa na busca pelos seus objetivos.
    Quando a principal saída de um projeto é um produto ou serviço para uso de terceiros, o Valor indica tanto a satisfação destes quanto a realização das estratégias comerciais.
    Aqui é importante destacar que o Valor também representa a Qualidade Extrínseca ou externa do produto ou serviço. Essa qualidade é imediatamente percebida pelo cliente e não é a mesma citada como segunda ponta do triângulo.
  • Qualidade: esta é a Qualidade Intrínseca ou interna do produto, e refere-se principalmente à sua confiabilidade e capacidade de adaptação. Por exemplo: um produto pode ser muito bem recebido por um cliente no primeiro momento – seu Valor foi percebido pelo cliente. No entanto, quando mudanças são necessárias mas de difícil e cara implementação, consideramos que a qualidade do produto é baixa, sofrível ou inexistente.
  • Restrições: e quem disse que o velho triângulo deveria ir para o lixo? Muito pelo contrário. É aqui, formando a terceira ponta do novo triângulo, que manifestamos nossa preocupação com Escopo, Prazos e Custos. Como reforça Jim, utilizando o mesmo padrão de apresentação dos valores do Manifesto Ágil, a colocação das restrições como apenas uma ponta do novo triângulo não significa dizer que elas não são importantes. Mas é considerável o impacto na crença de que a realização sem desvios do escopo, prazos e custos previstos seriam suficientes para determinar o sucesso de um projeto.
    E esta não é a única mudança. Além do livro de Jim, um outro trabalho a ser publicado em 2010, “Agile Product Management with Scrum³“, sugere um interessante tratamento das restrições. Das três – escopo, prazos e custos – uma é mais relevante para a realização dos objetivos do negócio. Apenas ela deveria ser fixada. As outras duas seriam tratadas com certa flexibilidade. Por exemplo: o prazo, o time-to-market, é considerado crucial para o sucesso de determinado produto. Sendo assim, tanto o escopo quanto os custos poderiam variar. É claro que não se trata de flexibilização total (e insana). Mas o cliente ou patrocinador aceitaria a flutuação dentro de uma faixa pré-estabelecida. Os custos ficariam entre $ 80 e $ 120, por exemplo. Também seria aceitável o possível corte de algumas funcionalidades opcionais (ou secundárias). Tudo para que o prazo, neste exemplo a restrição mais importante para o negócio, fosse atendido plenamente.

.:.

Me parece inevitável uma revisão da definição de fracasso pelo Standish Group. Assim como espero um PMBoK mais orientado para a adaptação do que para ações corretivas (que visam a colocação do trabalho nos “trilhos” de um plano). Como insiste Jim Highsmith em mais de um trecho do livro, “planos (e arquiteturas) devem funcionar como guias e não como camisas-de-força”.

Do outro lado, do Mundo Ágil, espero a compreensão de que o ROI (Retorno sobre o Investimento) não é a única unidade de medida ou preocupação que deve nortear um projeto ou mesmo indicar seu sucesso ou fracasso.

Mas… devo me segurar. Afinal, prometi uma série de artigos com provocações e questionamentos, não com conclusões. Portanto, deixo algumas questões: Como você mede o sucesso de seus projetos? E o fracasso? Você realmente acredita que um projeto cancelado significa um fracasso? Planos não realizados em sua plenitude são fracassos? Essas percepções são compartilhadas por todas as partes interessadas?

O papo seguirá. O próximo artigo será “O Mundo Mudou“. Inté!

.:.

Referências

  1. Guide to the Project Management Body of Knowledge – PMBoK® Guide, Fourth Edition.
    PMI – Project Management Institute. 2009.
  2. Agile Project Management – Second Edition.
    Jim Highsmith. Addison-Wesley, 2010.
  3. Agile Product Management with Scrum
    Roman Pichler. Addison-Wesley, 2010.

A figura utilizada no topo do artigo, flikr2298, é do Flikr e liberada como Creative Commons (by).

Bookmark / compartilhe
  • LinkedIn
  • Twitter
  • Facebook
  • email
  • del.icio.us
  • Rec6
  • Google Bookmarks
  • Add to favorites
  • Live
  • RSS
  • PDF
Creative Commons License
The Fracasso 2.0 by finito, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.

Artigos relacionados:

  1. O Novo Gerente de Projetos
  2. O Mundo Mudou
  3. [SOA # 8] – Processo de Gestão e Desenvolvimento

3 Tweets

{ 10 comments… read them below or add one }

3 Shigueru December 21, 2009 at 11:36

Olá Paulo,

Taí uma resposta clara pra um cenário que incomoda: etapa de testes que são reduzidas ou eliminadas (porque o cronograma tá apertado), comemoração de projetos que não entregam valor ou estão em discrepância com os objetivos da empresa (só porque os custos, prazos e escopo foram antendidos) , “esquecer” o Negócio da empresa.

(..) Você realmente acredita que um projeto cancelado significa um fracasso?

Sob a perpectiva de que um erro foi reconhecido e assumido, é um sucesso. Sob a perpectiva de que ele já nasceu incoerente com o negócio da empresa, é um fracasso. Depende (não consegui evitar o termo) do contexto.

Parabéns pelo artigo!

[]s

Shigueru.

4 admin December 21, 2009 at 12:00

Oi Shigueru,

Muito obrigado pelo comentário. Reparei agora que minhas perguntas, soltas como foram, podem ser perigosas. Sua colocação esclarece. Muitos projetos são experiências. Como tal, a organização deve estar preparada para erros e cancelamentos.

Abraços,

Paulo

6 Marcel Fleming January 8, 2010 at 09:05

Paulo.

Acho que tem algum ponto nesses seus artigos que eu não “peguei”. Um plano não é imutável em todo o horizonte do projeto, mas dentro de alguma janela ele deve ser estável – e nessa janela faz sentido observar desvios e tomar ações corretivas. A ação corretiva não precisa ser, necessariamente, voltar para seus parâmetros.

Peguemos como exemplo um Sprint em um projeto Scrum: pelo menos do que vi até agora, pelo menos nesse período deve-se buscar manter o escopo acertado na sessão de planejamento o máximo possível. Se o burndown não estiver acompanhando o combinado (ou seja, o plano), é preciso entender o porque e tomar ações corretivas e, de novo, até onde eu sei, não há nada na proposta ágil que impeça solicitar à equipe que faça algumas horas extras naquele sprint (por exemplo), se isso for justificável, para atender à entrega do escopo combinado – de novo se for justificável do ponto de vista do negócio.

Mesmo que, visando manter o ritmo de trabalho da equipe em limites bons (ou ideais?), e sendo isso possível, no mínimo a “cartilha” ágil reza que os resultados do sprint devem servir de insumo para o plano das próximas iterações, ajustando velocidade ou número de equipe. Ou seja, é uma ação corretiva – um paradigma diferente de ação corretiva… mas é uma ação corretiva.

Por fim, vale ressaltar que o PMBoK já expandiu o conceito do ântigo triângulo de ferro. Já é reconhecido que não é um triângulo. A forma proposta por Highsmith é apenas uma outra forma de vermos a coisa…

abs

7 admin January 8, 2010 at 09:17

Olá Marcel,

*Adaptação* é a palavra. E é claro que se trata de um sinônimo para *ação corretiva*. O que critiquei, e pelo jeito não deixei muito claro, é a ‘crença’ de que o plano está correto. Ou seja, ações corretivas, para o mind set tradicional, significa recolocar o projeto nos trilhos (do plano original).

A adaptação proposta por Highsmith (e vários outros) considera tudo, inclusive ou principalmente os planos.

Quanto ao PMBoK ter atualizado sua visão do ‘triângulo’: eu percebi. Mas considero distante da proposta do Highsmith. Em minha opinião, não é apenas uma outra perspectiva do mesmo objeto. Mas, ainda que seja, eu não percebo tal revisão (de preocupações) no restante do conteúdo do PMBoK.

Obrigado pela participação. Abraços,

Paulo Vasconcellos

8 Marcel Fleming January 8, 2010 at 09:57

“O que critiquei, e pelo jeito não deixei muito claro, é a ‘crença’ de que o plano está correto.”
-> Paulo, isto estava claro sim. Mas acho que num dado horizonte o plano tem que ser visto como estável (desculpe-me, mas não gosto da palavra “correto”) – foi isso que tentei mostrar com o exemplo scrum. Mas me parece que conceitualmente, estamos na mesma linha.

Sobre as mudança no PmBok, concordo que elas não estão ocorrendo de uma forma coerente. Na ed. 4, por exemplo, eles mudaram (para melhor) a explicação sobre ciclo de vida de projetos e tem claramente uma brecha para se alinhar com as metodologias ágeis. Mas não avançaram muito no geral – e, dado o fato de ser genérico, não sei dizer se deveriam mesmo avançar mais.

De qualquer forma, por que eu tenho batido um pouco nessa tecla: como o raphalbino bem colocou acima, nenhuma metodologia deve ser uma “camisa-de-força”. No caso do PMBoK, menos ainda, pois nem é uma metodologia.

Embora entenda e compartilhe muito de suas visões; embora eu me considere um cara mente aberta que, mesmo sendo PMP, bebe em muitas outras fontes (por exemplo, gosto muito do modelo do IPMA e do modelo de maturidade do Darci Prado, que não são ligados ao PMI) e seja um adepto da inovação, da quebra de paradigmas, tem havido um radicalismo da parte dos agilistas em relação aos conceitos do PMBoK, chegando a alguns pontos às raias da crítica pela crítica até mesmo aos GPs.

Ora, o PMI não tem culpa se há GPs e gps. Assim como você, vários (a maioria) dos projetos que conduzi fugiram em prazo e escopo, mas na média, sempre satisfizeram o cliente. Eu tenho um case em que o projeto quase falhou por que eu cedi a pressões e estava prejudicando a qualidade – mas conseguimos reverter a tempo – porém, aí sim o estouro de custo foi maior do que o “normal”.

Acredito em processos, mas processo não quer dizer “burocracia”. O livro do Berkun que você mencionou mostra isso de forma muito interessante (Cap. 10).

Não me preocupo com sua visão dessa questão: é claro para mim o que você pensa e onde quer chegar. Mas há muita gente nova radicalizando por aí, confundindo as próprias premissas do “agilismo” e isso em nada contribui com a nossa evolução como um todo.

9 admin January 8, 2010 at 10:19

@Marcel Fleming – Existem radicais de todos os lados. Eles sempre estarão por aí. Mas eu acho que de certa maneira eles contribuem sim para o debate. Aliás, o debate seria chato demais se contasse apenas com centro-esquerda, centro e centro-direita. Mas eu concordo contigo: tem hora que eles (ou nós?) esgotamos a paciência.

Aliás, caro Marcel, acho que esse papo (ágil x tradicional ou “change-driven” x “plan-driven”, como hilariamente pretendeu o BABoK) já tá meio batido. Sinceramente, eu pretendia outras discussões com a série sobre o “Novo Gerente de Projetos”. Acho que falhei.

Abraços,

Paulo Vasconcellos

10 Marcel Fleming January 8, 2010 at 10:34

@admin – Concordo com você. Mas não acho que você tenha falhado. Se não estou enganado, o advento ágil é quem tem gerado grande parte dessa discussão, assim acho meio natural que ela permeie a discussão do “Novo Gerente de Projetos”. Até meio que ia “vestindo a carapuça” achando que eu tinha voltado a esse assunto, mas vi que outros mencionaram. De qualquer forma, me desculpa se estou sendo insistente.
Então para mudar um pouco, estou tendo uma experiência com gestão de projetos de inovação (não restrito a TI) e antecipo que é um terreno fértil para subsidiar essa discussão, pois há projetos em que há um enorme complexidade na gestão de expectativas e muitas dificuldades em estabelecer objetivos claros e “smart”.

Leave a Comment

Spam Protection by WP-SpamFree

{ 2 trackbacks }

Additional comments powered by BackType

Previous post:

Next post: