Stonehenge e a Gestão de Mudanças

Sempre gostei muito de ler. Tanto livros técnicos quanto literatura em geral.

Uma coisa muito interessante que percebo é que, por causa de minha atuação em gerenciamento de projetos, acabei por configurar uma espécie de “filtro mental” que me permite enxergar belíssimos “cases” de GP nos mais variados contextos.

Um dos autores que me inspira muitos destes “cases” é o inglês Bernard Cornwell [1]

Para abordar o tema “gestão de mudanças” vamos analisar o livro “Stonehenge”. Nele Cornwell elabora a trama em torno da construção do círculo de pedras mais famoso da Inglaterra (condado de Wiltshire).

Transcrevo um trecho da “orelha” do livro, para ilustrar melhor o tema:

Camaban, o aleijado pária da tribo, torna-se um grande visionário e temido feiticeiro, que irá forçar o irmão mais novo, Saban, a embarcar em uma arriscada jornada para construir o templo na colina verdejante. Saban é um homem de paz, e com suas habilidades erguerá o enorme monumento...

Podemos então identificar Camaban, o feiticeiro, como principal cliente desta empreitada, bem como Saban como o gerente do projeto.

Cornwell registra magistralmente em sua narrativa diversos dos dramas sofridos ao longo da execução do projeto: pressa do cliente, mudanças no escopo, gestão de pessoas, problemas com fornecedores, e sempre vemos o hábil Saban lidando com estes problemas para finalizar o projeto, alguns destes problemas são ilustrados no trecho abaixo:

(...) Camaban continuava irritado.

- Por que demora tanto? – perguntava constantemente.

- Porque a pedra é dura – respondia Saban constantemente.

- Chicoteie os escravos! – exigia Camaban.

- E vai demorar o dobro do tempo – ameaçava Saban, e então Camaban ficava com raiva e jurava que Saban era seu inimigo.

Quando metade dos pilares do círculo do céu estava no lugar, Camaban exigiu um novo refinamento.

- O círculo do céu vai ficar nivelado, não vai? – perguntou a Saban.

- Nivelado?

- Plano – disse Camaban com raiva, fazendo um gesto de alisamento com a mão. – Liso como a superfície de um lago.

Saban franziu a testa.

- O templo é inclinado – disse ele, apontando para a suave queda no terreno - , de modo que, se os pilares do círculo do céu são todos do mesmo tamanho, o círculo de pedras vai seguir a encosta.

- O círculo deve ser plano! Insistiu Camaban. – Deve ser plano!

(...) Saban... prometeu fazer o círculo do céu plano, mesmo sabendo que isso tomaria mais tempo ainda.[2]

Para não fazer maiores revelações sobre o enredo [3], vamos relembrar o processo de gestão de mudanças:

O PMBok (2008:424) define controle de mudanças como a “identificação, documentação, aprovação ou rejeição e controle feitas nas linhas de base do projeto”. “Realizar o controle integrado de mudanças” é um processo que está contemplado na área de conhecimento “Gerenciamento da integração do projeto”. Segundo o PMBoK (2008:71):

No contexto de gerenciamento de projetos, integração inclui características de unificação, consolidação, articulação e ações integradoras que são essenciais para o término do projeto, para gerenciar com sucesso as expectativas das partes interessadas e atender aos requisitos.

Todo projeto está sujeito a mudanças. Cabe ao gerente do projeto analisar os impactos da solicitação da mudança nas restrições do projeto - normalmente chamada de tríplice restrição: Escopo, prazo e custos, que refletem na qualidade do mesmo. É o que Saban faz inicialmente ao ser confrontado com o problema de gestão de pessoas, e posteriormente, ao receber a solicitação de mudança, para fazer todas as pedras niveladas.

No contexto de gestão de projetos é importante salientar que mudanças podem ser solicitadas por qualquer parte interessada envolvida no projeto, e mesmo podendo ser iniciadas verbalmente, devem ser registradas formalmente, de forma escrita e submetidas ao processo de gestão de mudanças, para avaliação dos impactos da mudança nos objetivos do projeto para aprovação ou rejeição. (PMBoK 2008:94).

Uma vez que a solicitação de mudança seja aprovada, pode ser necessário rever ou revisitar as estimativas de custos, prazos, documentação do projeto, análise de riscos, escopo, etc. Além disso, se o projeto estiver sendo fornecido por meio de um contrato, deve-se celebrar com o cliente um “Termo Aditivo ao contrato”, para formalizar a mudança e garantir sua correta remuneração.

Notas

[1] para conhecer mais do trabalho deste autor, recomendo a trilogia “As Crônicas de Artur” (O Rei do Inverno, O Inimigo de Deus e Excalibur), a trilogia “A Busca do Graal” (O Arqueiro, O Andarilho e O Herege) e a Série “As Crônicas Saxônicas” (O Último Reino, O Cavaleiro da Morte, Os Senhores do Norte, A Canção da Espada e Terra em Chamas), cada um deles riquíssimo em bons exemplos que podem ser apropriados para a compreensão do mundo corporativo.

[2] Cornwell, Bernard. Stonehenge. 2ª edição. Rio de Janeiro: Editora Record, 2000, p. 453.

[3] prefiro não roubar do leitor o prazer de desbravar o texto original.

[4] PMBoK. Um guia do conhecimento em Gerenciamento de Projetos. 4ª Edição. Pennsylvania/USA: PMI - Project Management Institute, Inc. 2008.

A importância de uma boa definição do escopo

Vamos assistir à seguinte esquete:



A sátira tem como um de seus objetivos apontar as incoerências da realidade, apresentando-as de forma exagerada, cômica. O grupo inglês Monty Python apresenta, de forma brilhante, algo que pode acontecer com qualquer gerente de projeto que se esqueça, ainda que parcialmente dos processos de gerenciamento de escopo.


O PMBok (2008:103) define gerenciamento de escopo como os “...processos necessários para assegurar que o projeto inclui todo o trabalho necessário, e apenas o trabalho necessário para terminar o projeto com sucesso.”. Apresenta, também, cinco processos para o gerenciamento do escopo do projeto:

• Coletar os requisitos (definição e documentação das necessidades para alcançar os objetivos do projeto);
• Definir o escopo (descrição detalhada do projeto e do produto);
• Criar a EAP (subdivisão do trabalho/entregas em componentes menores e mais facilmente gerenciáveis) [1];
• Verificar o escopo (formalização do aceite das entregas concluídas do projeto);
• Controlar o escopo (monitoramento do progresso do escopo do projeto/produto, bem como o controle integrado de mudanças).

No vídeo em questão, podemos perceber que houve uma sequência de falhas na execução destes processos, que culminaram no confronto cliente/projetista que serve de motivação para o esquete.

Sem grande esforço é fácil de inferir que os processos “Coletar os requisitos” e “Definir o escopo” foram ignorados ou conduzidos de maneira imprópria.

Se o “Michelangelo”, responsável pelo projeto, tivesse dedicado algum tempo entendendo o que estava sendo contratado, por meio da compreensão dos requisitos e da definição do escopo contratado, tal cena não teria ocorrido.

O cliente, em muitos casos, tem uma ideia do que precisa, mas pode não conseguir expressar em termos técnicos. Cabe ao gerente do projeto captar as expectativas do cliente, facilitando a manifestação dos desejos do cliente, garantindo que não haja dúvidas para nenhuma das partes. Após coletar/documentar os requisitos pode cristalizar tais desejos e expectativas na declaração de escopo do projeto.

Conforme o PMBoK (2008:115), a declaração de escopo do projeto:

Descreve detalhadamente as entregas do projeto e o trabalho necessário para criar as mesmas. (...) Pode conter exclusões explícitas do escopo que podem auxiliar o gerenciamento das expectativas das partes interessadas. (...) direciona o trabalho (...) durante a execução e fornece a linha de base para avaliar se as solicitações de mudança ou trabalho adicional estão contidos no escopo ou são externos aos limites do projeto.

A declaração inclui, de forma direta ou por referência a outros documentos do projeto os seguintes itens:

• Descrição do escopo do produto;
• Critérios de aceitação do produto;
• Entregas do projeto;
• Exclusões do projeto;
• Restrições do projeto.

Outro ponto que devemos abordar é o “Gold plating”[2], que é inserir mais funcionalidades ou atributos ao projeto, que não constam do escopo original, com o objetivo de “encantar o cliente”. Isso fica evidente pela fala “É que eu queria fazer uma verdadeira última ceia, não é qualquer última ceia, uma última refeição ou um lanche final...”. O “gold plating” gera trabalho desnecessário e pode gerar muito retrabalho – “Não gostou do canguru? Tudo bem, eu pinto um apóstolo por cima”.

O gerente de projetos deve, então, entender o escopo, seja por meio de entrevista ao cliente, workshops com o cliente ou qualquer outro método que se faça necessário, documentar este escopo e formalizá-lo. Ao fazer isso se pode focar na execução do projeto, atentando-se para que o que foi contratado e apenas o que foi contratado seja entregue ao cliente.

Notas
[1] – EAP – Estrutura Analítica do Projeto
[2] – Alguns autores utilizam o termo “dourar a pílula” para traduzir o termo, mas como em português “dourar a pílula” significa “apresentar algo difícil ou desagradável como coisa fácil de aceitar”, e tem origem no antigo habito que farmacêuticos tinham de embrulhar suas pílulas, amargas, em finos papéis para torna-las mais atraentes para os clientes. Portanto prefiro utilizar o termo “enfeitar o pavão” ou “gold plating” mesmo.

Da Importância Das Lições Aprendidas


Para suscitar nossa discussão, vamos ler a seguinte historinha:

Você vai passar um projeto novo e complexo para um de seus funcionários mais capazes: Sam. Ele tem pouca experiência, mas é muito inteligente e interessado – por isso foi escolhido para esse projeto. Ao entregar a Sam uma enorme pilha de documentos, você diz a ele: “Primeiro, quero que leia todo esse material e comece a ter uma ideia do que temos em mão”. Então fala da origem do projeto, das outras pessoas envolvidas e da meta global. E diz “Não tenho muita certeza de como deve ficar o resultado final. O que você acha?”. Isso os conduz a uma boa discussão, mas você não especifica nenhum produto final concreto. Em vez disso, sugere que Sam consulte uma colega, Barb, que fez um projeto semelhante recentemente. (...) Após meia hora, termina a conversa com Sam, informando-o de que esse projeto é sua prioridade. “Qual é o prazo de entrega?” Ele quer saber. Sua resposta: “Assim que conseguir terminá-lo”[1]

Como todos vocês conhecem gerenciamento de projetos, sabem que nosso Sam acabou de entrar em uma fria – um projeto que não tem escopo, produto nem prazos definidos. Pelo texto vemos que o melhor conselho dado ao Sam foi “consultar Barb, que fez um projeto semelhante recentemente”.

O conselho pode ser resumido em “consulte as lições aprendidas”.
Mas o que são lições aprendidas?

O Guia PMBOK - (2004: 230) do PMI define Processo de Lições Aprendidas como:

Uma definição de lições aprendidas seria o conhecimento adquirido pela experiência, podendo ser essa experiência positiva ou negativa (CHAVES et. al., 2006: 110). Esses registros devem ser de simples abstração, fáceis de serem acessados, relevantes ao desenvolvimento de projetos e contextualizados para os novos projetos.

Registrar as lições aprendidas em seus projetos mostra o qual madura em gerenciamento a organização se encontra, pois, primando sempre pela melhoria continua de processos, através do uso de ferramentas diversas erros podem ser evitados e soluções mais acertadas podem ser encontradas. Como cita Kerzner (2006: 51): “Se não “documentar” as lições aprendidas, a empresa pode rapidamente regredir da maturidade para a imaturidade e gestão de projetos. O conhecimento é perdido, e os erros do passado se repetem.”

Uma boa lição aprendida possui as seguintes características: É Documentada de forma simples, clara e rastreável, é relevante e contextualizada quanto a sua utilização - O conhecimento deve evidenciar sua utilidade em aplicações práticas.

Referências bibliográficas

CHAVES, L. E.; SILVEIRA NETO, F. H. da; PECH, Gerson; CARNEIRO, M. F. S. Gerenciamento da Comunicação em Projetos. Rio de Janeiro: Editora FGV, 2006.

KERZNER, H. Gestão de Projetos: As melhores práticas. 2ª Edição. Porto Alegre: Bookman, 2006

PMBOK, Guia. Um guia do conhecimento em Gerenciamento de Projetos. 3ª Edição. Pennsylvania/USA: PMI - Project Management Institute, Inc. 2004.

Notas:

[1] Retirado de :Tulgan, Bruce; Não Tenha Medo de ser Chefe – Na obra em questão o exemplo é utilizado para exemplificar quais tipos de ações gerenciais deveriam ter sido tomadas, mas esta história também se mostra muito útil para ilustrar e motivar uma discussão sobre lições aprendidas.