Projetos em grande escala como sistemas complexos – Gerenciando o Scope Creep

O famoso ditado de Northcote Parkinson, “O trabalho se expande para preencher o tempo disponível para sua conclusão”, pode ser excessivamente otimista. Infelizmente o trabalho tende a se expandir muito além do tempo e do dinheiro orçados para sua conclusão, particularmente para projetos complexos. Por exemplo, estimativas publicadas no ano passado em Comunicações da ACM (Association for Computing Machinery) indicam que as empresas americanas gastaram aproximadamente US $ 59 bilhões em 1995 em custos excedentes e US $ 80 bilhões adicionais em projetos cancelados de tecnologia da informação (TI). Essas estimativas não incluem excedentes em projetos do governo ou do setor público. Um estudo semelhante da Coopers & Lybrand no Reino Unido indica que 85% dos projetos de TI estão acima do orçamento, não cumprem sua programação ou não atendem às expectativas dos clientes.

Embora os projetos de desenvolvimento de TI e software possam ser as áreas mais visíveis nas quais o trabalho se estende além de seus parâmetros originais, os esforços de reengenharia de processos, iniciativas de mudança organizacional abrangentes e projetos de construção em larga escala certamente não estão isentos. Tomemos, por exemplo, uma pequena cidade na Carolina do Norte que está construindo um reservatório para seu abastecimento de água municipal. A estimativa original para o projeto há cinco anos foi de US $ 5,4 milhões, com um prazo de dois anos para a construção. Hoje, o custo estimado é de US $ 8 milhões. A construção mal começou e agora é projetada para levar três anos.

Dadas essas estatísticas preocupantes, parece justo dizer que grandes projetos raramente, ou nunca, permanecem dentro de suas especificações originais e cumprem suas metas previstas de tempo e dinheiro. Na verdade, qualquer programa ou projeto de natureza complexa que compreende um período de tempo prolongado, requer um investimento monetário significativo de vários componentes que precisam ser gerenciados simultaneamente, se torna vulnerável apesar dos heróicos esforços tradicionais de gerenciamento de projetos. Essa tendência de tais projetos se expandirem além de seus limites iniciais e, portanto, se estenderem muito além de suas previsões, é freqüentemente chamada de “escopo incontrolado”. Neste artigo, examinamos esse fenômeno visualizando grandes projetos como sistemas complexos. Ao entender o descontrole de escopo neste contexto, podemos começar a identificar como e por que isso ocorre. Equipado com esse conhecimento, pessoas, equipes e organizações capacitadas podem planejar e mitigar com mais eficácia os efeitos do descontrole de escopo, adotando uma perspectiva mais realista e dinâmica sobre o processo de gerenciamento de projetos.

A Dinâmica do Scope Creep

Como o descontrole de escopo começa e o que faz com que ele se construa ao longo do tempo, levando a atrasos e atrasos dispendiosos? As organizações iniciam projetos para atender a uma necessidade percebida. Por exemplo, a cidade mencionada acima enfrentou escassez de água periódica durante períodos de seca, por isso decidiu construir um reservatório para atender às suas necessidades de água. Em um mundo ideal, após algum atraso, o projeto deveria ser  completado dentro de seu orçamento original e dentro do cronograma, e a necessidade percebida seria preenchida (B1).

A quantidade de dinheiro investido em um projeto limita a quantidade de trabalho que pode ser realizado e, portanto, geralmente define o escopo do projeto – pelo menos inicialmente. Quanto maior o projeto, e quanto mais pessoas, departamentos e agências envolvidos, mais complexa a governança se torna. Por exemplo, em uma empresa de TI, um esforço de desenvolvimento de produto em larga escala requer informações de vários departamentos, cada um com seu próprio gerenciamento e suas próprias prioridades. Vários subprojetos do esforço maior podem acabar competindo entre si pelas habilidades de testadores, programadores de bancos de dados ou escritores técnicos, tornando a governança geral complexa. A competição por recursos limitados se intensifica à medida que o número de subprojetos se expande, tornando o gerenciamento do esforço geral mais desafiador.

Quando a governança é complexa, os gerentes acham difícil tomar decisões em tempo hábil e atender às consequências de longo prazo de cada decisão. Essas dificuldades ameaçam a precisão das estimativas de cronograma. À medida que os prazos se aproximam e a pressão do tempo sobe, as pessoas tendem a pegar atalhos para manter o projeto no caminho certo. Em um projeto de desenvolvimento de software, por exemplo, os atalhos geralmente significam desenvolvimento paralelo inadequado – talvez desenvolvendo aplicativos que dependam de módulos de nível inferior antes que os módulos de nível inferior sejam totalmente projetados. Pegar atalhos em um projeto de construção pode significar aceitar a proposta mais baixa sem qualificar o fornecedor, não permitindo tempo suficiente para coordenar o trabalho dos vários subcontratados, ou até deixando de permitir a cura do cimento adequadamente. No curto prazo, os atalhos podem parecer aliviar pressões de cronograma (B2), mas na verdade é um exemplo da clássica estrutura arquetípica “Fix That Fail”. Em um cenário “Soluções que Falham”, uma ação que soluciona um problema no curto prazo realmente exacerba a mesma condição a longo prazo. Assim, ao longo do tempo, os atalhos geralmente resultam em retrabalho, o que inevitavelmente cria ainda mais pressão de cronograma (R3)

O retrabalho também aumenta o custo. À medida que o custo de um projeto aumenta, os gerentes de projeto precisam justificar os gastos adicionais para a alta gerência ou para seus constituintes. Para fazer isso, eles geralmente “descobrem” novas features para tornar a despesa adicional mais palatável. Por exemplo, um funcionário eleito pode dizer a um grupo irado de contribuintes: “É claro que uma barragem custando tanto incluirá uma área de recreação.” Ou os constituintes podem decidir que uma empresa tão cara deve incluir uma área de recreação e pressionar os funcionários para fazer uma . As expectativas de um projeto de TI podem aumentar quando o departamento de vendas assegura aos clientes insatisfeitos: “Ah, temos uma nova versão que abordará sua preocupação”. Garantias e premissas como essas aumentam as expectativas dos clientes e expandem o escopo do projeto (R4).

À medida que o escopo do projeto aumenta, a rede de interações e dependências entre tarefas, subprojetos, departamentos e agências se torna ainda mais complexa. Essa complexidade crescente pode levar a atrasos. Por exemplo, em um projeto de construção, se um subcontratado tiver que esperar por um segundo para concluir suas tarefas, ele poderá precisar assumir outro trabalho nesse ínterim. Ele pode então não ter o pessoal imediatamente disponível para trabalhar no projeto original quando o primeiro subcontratado estiver finalmente pronto para ele. Atraso cria ainda mais pressão de prazo e reforça a dinâmica do escopo descontrolado.

Tais interações e dependências também dificultam a estimativa precisa de custos. Os atrasos podem agravar ainda mais o problema, tornando as estimativas de custos ainda menos precisas. Se os custos reais forem muito mais altos do que as estimativas originais, a pressão sobre os funcionários e gerentes para justificar os custos aumenta, o que pode influenciar ainda mais as expectativas do projeto e causar um aumento ainda maior no descontrole de escopo (R5).

A complexidade da governança afeta mais do que a oportunidade das decisões. Também afeta a capacidade dos tomadores de decisão de ver os efeitos de suas decisões – tanto em outros aspectos do projeto quanto no futuro. Com menos visibilidade para efeitos posteriores, as decisões que parecem dar resultados locais positivos podem ter consequências globais negativas. Portanto, a qualidade das decisões pode diminuir – aumentando a probabilidade de retrabalho adicional e criando complexidade adicional (R6).

Assim, a tendência dos grandes projetos de aumentar seu escopo encontra suas raízes em duas hipóteses subjacentes. A primeira é que podemos gerenciar um projeto simplesmente gerenciando suas partes. Essa prática nos leva a ignorar o impacto sistêmico de decisões locais aparentemente pequenas, o que, por sua vez, pode minar estimativas iniciais de tempo e custo e aumentar a complexidade do projeto. A segunda é que assumimos que podemos estimar cronogramas e custos com precisão antes de iniciar o trabalho. Mas, muitas vezes, quando um projeto custa mais ou demora mais do que o esperado, respondemos presumindo que ele deve incluir recursos adicionais ou adicionando mais para justificar o aumento de custo ou tempo – aumentando o descontrole do escopo.

Além do Gerenciamento Tradicional de Projetos

Até hoje, a maioria das explicações sobre o Scope Creep se origina de uma visão linear e sequencial dos projetos e de como eles são gerenciados. Por exemplo, o Project Management Institute define as cinco fases de gerenciamento do projeto como iniciar, planejar, executar, controlar e fechar. Este modelo assume que uma fase é concluída antes do próximo começar e que devemos retornar às fases anteriores somente quando ocorrerem problemas.

Usando essa estrutura sequencial, vários autores escreveram que o Scope Creep ocorre quando a fase de planejamento está incompleta. Por exemplo, alguns sugerem que, se os objetivos e as “entregas” do projeto não estiverem totalmente definidos ou se as falhas do projeto não forem claras, o projeto excederá suas projeções originais de custo e cronograma. Outros atribuem o Scope Creep a requisitos mal definidos ou financiamento insuficiente. Outro conjunto de explicações enfoca os problemas que ocorrem durante a fase de controle; por exemplo, mudanças mal documentadas nas especificações do projeto.

Todas essas explicações provavelmente estão corretas até certo ponto. No entanto, mesmo se uma equipe aderir rigidamente a essa estrutura de gerenciamento de projetos e concluir cada etapa com perfeição aproximada, ainda poderá ocorrer o descontrole de escopo, especialmente em projetos grandes e complexos. Bom, o gerenciamento linear de projetos é necessário. No entanto, com frequência temos Scope Creep, e o gerenciamento linear é insuficiente para evitar o problema.

A desvantagem do modelo tradicional de gerenciamento de projetos é que ele não explica adequadamente o fato de que um grande projeto – como construir um reservatório, desenvolver um software grande e complexo ou escrever um grande currículo de treinamento – é na verdade um grande sistema com múltiplas partes interativas. De acordo com John Sterman, professor do M. I. T., “Projetos de grande escala pertencem à classe de sistemas dinâmicos complexos. Tais sistemas são altamente complexos, consistindo em múltiplos componentes interdependentes,são altamente dinâmicos, envolvem múltiplos processos de feedback,  envolvem relacionamentos não-lineares e envolvem tanto dados tangíveis e intangíveis. Ao descrever problemas nesses tipos de sistemas, a autora Meg Wheatley diz: “Eles não podem ser compreendidos suficientemente antes ou durante o tempo em que estão ocorrendo; portanto, previsão e controle são impossíveis”. Em outras palavras, as interações entre as tarefas, os subprojetos e as estruturas de governança de um projeto complexo tornam praticamente impossível definir as entregas do projeto ou captar os requisitos de recursos com antecedência.

A dinâmica do Scope Creep

Por exemplo, no desenvolvimento de software, os gerentes geralmente dividem os projetos em vários módulos – cada um dos quais deve ser projetado e desenvolvido de forma independente e depois combinado em um produto completo. Eles então dividem o trabalho de cada módulo em uma série de tarefas, que podem ser sequenciadas e colocadas em uma linha do tempo. Parece lógico pensar que, se essas tarefas são realizadas da maneira prescrita, sua conclusão deve constituir o projeto total. Na prática, no entanto, o grau de interdependência entre os módulos geralmente não fica evidente até que as equipes tenham investido muito esforço em design e desenvolvimento. Nesse ponto, os componentes geralmente exigem mais design, codificação e teste do que o rçamento inicial para fazer os módulos funcionarem juntos.

Igualmente importante, à medida que as interdependências entre os diferentes módulos vêm à luz, o escopo do projeto muda – mesmo que o plano de projeto não o faça – porque as pessoas envolvidas obtêm novas idéias sobre o que o produto deve oferecer. Por exemplo, um projeto de software que começou como uma reescrita do código para corrigir um problema evolui quando os projetistas percebem que resolver o problema facilita a implementação de uma solicitação do cliente que era difícil de implementar no código antigo. Para satisfazer o cliente, eles criam a solicitação na fase de reescrita. Uma única adição como essa normalmente não representa um problema. No entanto, quando uma reescrita é grande e dispendiosa, os gerentes podem ser pressionados a adicionar várias dessas solicitações de clientes para justificar as despesas do projeto. A abordagem padrão para gerenciamento de projetos deixa de considerar essas mudanças nas expectativas. Então, o que começou como uma correção simples pode inesperadamente se tornar um grande projeto para atender às demandas dos clientes.

Sterman identifica dois tipos de complexidade em projetos: combinatória e dinâmica. A complexidade combinatória é criada pelas atividades paralelas e sequenciais que ocorrem em um projeto grande e complexo – por exemplo, em um grande projeto de construção, todas as autorizações necessárias antes do início da construção. As ferramentas tradicionais de gerenciamento de projetos, como os gráficos PERT, CPM e GANTT, destinam-se a ajudar as pessoas a lidar com esses detalhes.

Por outro lado, a complexidade dinâmica é criada pelos múltiplos processos de feedback, atrasos de tempo e relações causais não-lineares que existem em qualquer projeto grande. Como as interações entre múltiplas variáveis ao longo do tempo impulsionam esse tipo de complexidade, elas podem crescer geometricamente ou mesmo exponencialmente à medida que elementos adicionais entram no sistema. Por exemplo, a visão tradicional afirma que adicionar uma quarta tarefa a três que já estão agendadas aumentaria a carga de trabalho proporcionalmente – ou seja, 33%. No entanto, esse cálculo não leva em conta o fato de que a nova tarefa interage com cada uma das tarefas existentes, na verdade, duplicando as interações entre tarefas e potencialmente aumentando a quantidade de trabalho em muito mais de um terço. Por essa razão, a complexidade dinâmica contribui significativamente para o fenômeno do Scope Creep e não pode ser adequadamente abordada usando abordagens lineares padrão.

Mitigando o Scope Creep

Claramente, precisamos ampliar nosso pensamento sobre gerenciamento de projetos. Felizmente, existem várias maneiras de fazer isso:

Complexidade Dinâmica da Superfície. A primeira chave para atenuar o aumento do escopo é encontrar maneiras de exibir os processos de feedback, atrasos de tempo e relacionamentos não lineares em um projeto grande e complexo. Aqui estão algumas sugestões:

• John Sterman demonstrou o valor de usar a modelagem de dinâmica do sistema em projetos de grande escala em conjunto com ferramentas tradicionais. Essa abordagem pode ajudar a expor muitas das interações entre tarefas, subprojetos e estruturas de governança que, em última análise, levam à distorção do escopo e podem tornar explícitas muitas suposições que muitas vezes permanecem não ditas. Com essas informações, os tomadores de decisão e os gerentes de projeto podem tomar decisões mais informadas sobre mudanças nas condições externas, mudanças propostas na estratégia, alocação de recursos, impactos de atrasos e até mesmo a viabilidade do projeto ao longo do tempo.
• Se não for prático usar um modelo de dinâmica do sistema, desenhar diagramas de loop causal pode ajudar os gerentes a identificar ciclos de feedback e relações causais separados por tempo e espaço. A discussão das interações e dependências entre vários fluxos de trabalho pode criar uma compreensão mais rica das complexidades envolvidas.
• Com um conhecimento básico de pensamento sistêmico e diagramas de loop causal, os tomadores de decisão reconhecem muitos “atalhos” como “Soluções que falham”. Mas, como é difícil detectar padrões de comportamento durante a implementação de um projeto, os gerentes devem antecipar e documentar possíveis problemas que poderão acontecer. Uma maneira de fazer isso é identificar quaisquer arquétipos de sistemas operando em projetos anteriores, documentá-los e compartilhá-los com a equipe do projeto. A equipe precisa avaliar continuamente se padrões similares estão surgindo no presente projeto e tomar as medidas apropriadas para evitar cair nas mesmas armadilhas. Antecipar essas situações, documentá-las antecipadamente e nomear alguém para sinalizá-las se surgirem, pode levar a decisões mais inteligentes quando a ação começar em uma iniciativa importante.
• O processo de tomada de decisão em grandes projetos é muitas vezes extremamente complexo, pesado e sujeito a pressões externas. Essas pressões podem incluir considerações políticas, a cultura da organização, práticas de gestão arraigadas e restrições orçamentárias. Devido à complexidade do processo de tomada de decisão, os gerentes de projeto geralmente tomam decisões sem considerar como podem afetar o restante do sistema. Uma maneira de simplificar a tomada de decisões e ajudar a identificar conseqüências não intencionais é usar uma matriz de decisão. Para fazer isso, faça uma lista dos possíveis resultados na parte superior de uma página. Em seguida, converse sobre as possíveis soluções em consideração e liste-as na lateral da página. Discuta as diferentes combinações resultantes representadas por cada “célula” na matriz antes de tomar qualquer decisão. Use um processo de classificação para determinar qual célula ou células melhor atende aos resultados desejados.
• O planejamento de cenários oferece outra maneira de identificar e explorar os possíveis resultados – tanto previsíveis quanto improváveis – das decisões que estão sendo consideradas. Para uma aplicação simples do planejamento de cenário, leia Peter Senge no livro A Dança da Mudança: Os Desafios para Sustentar o Momento nas Organizações Aprendizes (Doubleday, 1999), pp. 187-190. Durante o processo de planejamento de cenário, os gerentes de projeto e as equipes também podem identificar algumas “Soluções que Falham” adicionais a serem evitadas.

Repensar abordagens para orçamentos e cronogramas. Também precisamos repensar a suposição comum de que podemos fazer previsões precisas de custo e cronograma antecipadamente em um projeto grande. Essa expectativa não é realista, devido à natureza intrinsecamente variável desses projetos. Portanto, precisamos de uma abordagem “escalonável” para orçamentos e cronogramas, em que revisamos e atualizamos regularmente as estimativas de tempo e dinheiro. Essas revisões devem incluir um cronograma para as decisões relacionadas à mudança do projeto, o redimensionamento ou até mesmo cancelar o projeto. Com o tempo, à medida que aprendemos mais sobre o trabalho envolvido, as estimativas devem se tornar mais precisas.

Nenhuma organização pode lançar um projeto sem ter alguma ideia sobre a quantidade de dinheiro e tempo envolvidos. Os gerentes devem, portanto, fornecer uma série de estimativas iniciais de custo e cronograma, juntamente com uma margem de erro e um plano de revisão com áreas de escape, conforme descrito acima. Essas estimativas e as revisões internas ajudam a evitar que as pessoas se sintam presas e traídas quando grandes projetos ultrapassam o orçamento e se atrasam.

Use o propósito original como uma âncora. Há uma tendência de usar as expectativas atuais como um tipo de ponto de ancoragem ao considerar mudanças no escopo de um projeto. Essa propensão pode ser perigosa, porque as expectativas atuais podem ter mudado significativamente desde o início do projeto. De fato, as dinâmicas por trás do Scope Creep são semelhantes às da estrutura arquetípica de “Metas a Deriva”. Em “Metas a Deriva”, dois loops de equilíbrio interagem para fazer com que metas e padrões diminuam com o tempo. No Scope Creep, uma série de processos de reforço constantemente “elevam o padrão” e impedem que o projeto seja finalizado dentro de suas projeções originais. Para ajudar a evitar este processo, volte ao propósito original do projeto e use-o como um ponto de referência. Por que o projeto foi iniciado em primeiro lugar? Se você decidir mudar seu escopo, quais serão as ramificações?

Siga boas práticas de gerenciamento de projetos. Por fim, continue usando boas práticas de gerenciamento de projetos. Muitas ferramentas tradicionais continuam sendo essenciais para acompanhar o progresso de qualquer projeto. No entanto, lembre-se que em um sistema complexo como um grande projeto, o todo não é igual à soma de suas partes; o todo inclui a soma de suas partes, bem como as interações entre todos os componentes.

Além do Velho Paradigma

Albert Einstein é frequentemente citado dizendo: “Os problemas significativos que enfrentamos não podem ser resolvidos no mesmo nível de pensamento em que estávamos quando os criamos”. O descontrole de escopo é um problema. Até hoje, a maioria das tentativas de controlar o Scope Creep usaram a lógica aditiva linear para neutralizar o que é um fenômeno altamente complexo e dinâmico. Esse modo de pensar sequencial coloca a culpa pelo escopo indesejado em práticas inadequadas de gerenciamento de projetos. Mas, em vez de correr para tentar novas tecnologias de gerenciamento de projetos ou culpar as pessoas por não implementarem as mais antigas, o que realmente precisamos é de uma nova maneira de entender grandes projetos como sistemas complexos. Neste artigo, oferecemos abordagens que não são visíveis a partir da abordagem linear tradicional. Acreditamos que essas ideias podem servir como oportunidades de aprendizado e como sementes para outras soluções. Aprender a ver grandes projetos como sistemas complexos pode não ser uma revolução, mas achamos que é um primeiro passo digno para uma evolução possível e necessária na maneira como as organizações operam.

Próximos Passos

• Circule o artigo entre os membros da equipe do seu projeto e discuta como os conceitos podem se aplicar ao seu trabalho. Pergunte: “Quais idéias do artigo mais chamaram a atenção de vocês?” “Houve alguma parte do artigo que pareceu especialmente verdadeira para nós?” “Como pensar em nosso projeto como um sistema complexo nos ajuda a tomar melhores decisões em longo prazo?
• Faça uma lista de atalhos que você pode tomar (ou ter) em seu projeto para mantê-lo dentro do prazo. Quais podem ser alguns efeitos indesejáveis a longo prazo desses atalhos?
• Crie um diagrama de loop causal capturando os relacionamentos entre os vários aspectos do seu projeto. Use este exercício para destacar e desafiar suposições sobre como os elementos do seu projeto afetam uns aos outros.
• Documente o objetivo do projeto e o que se espera que ele realize e pergunte se as expectativas se expandiram durante as revisões regulares.
• Indique um “historiador” para extrair dados de projetos anteriores, identificando padrões de comportamento ou arquétipos que levaram a problemas. Eduque a equipe do projeto sobre essas áreas problemáticas para que todos possam observar padrões semelhantes no projeto atual.

Autora: Andrea Shapiro, Ph. D., is an internal organizational learning consultant for Nortel Networks. Her work emphasizes learning, communication, and systems thinking (ashapiro@nortelnetworks.com). Carol Lorenz, Ph. D., of Carol Lorenz and Associates, is an independent contractor who worked at Nortel for a number of years. Her work emphasizes learning, organization effectiveness, and systems thinking (lorenzc@mindspring.com).

Link para o artigo original: https://thesystemsthinker.com/large-scale-projects-as-complex-systems-managing-scope-creep/

Tradução: Rodrigo Zambon

Rodrigo Zambon

Encarregado de Dados – DPO do Governo do Estado do Espírito Santo e Coordenador da Política de Dados Abertos da Secretaria de Estado de Gestão e Recursos Humanos. Cientista de Dados pela USP. Professor de Métodos Ágeis – Scrum e Kanban na Universidade de Vila Velha – UVV.