Scope Creep – Projetos de larga escala comparado à Sistemas Complexos

Continuamos nossa série sobre Scope Creep, caso queira acompanhar acesse Como evitar o Scope Creep, mas hoje não vou falar especificamente sobre Tecnologia, vamos entender e comparar um pouco os projetos de larga escala comparado à sistemas complexos.

O agora famoso adágio de C. Northcote Parkinson1, “O trabalho se expande de modo a 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, as 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 de custos excedentes e um adicional de US $ 80 bilhões em projetos cancelados de tecnologia da informação. Essas estimativas não incluem superações em projetos governamentais ou de setor público. Um estudo semelhante da Coopers & Lybrand no Reino Unido indica que 85 por cento dos projetos de TI estão acima do orçamento, perdem a programação ou não atendem às expectativas dos clientes.

Embora os projetos de desenvolvimento de TI e de software possam ser as áreas mais visíveis em que o trabalho se estende além de seus parâmetros originais, os esforços de reengenharia do processo, as iniciativas de mudança organizacional abrangentes e os 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 uma janela 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 os grandes projetos raramente, se alguma vez, permanecem dentro de suas especificações originais e cumprem suas metas previstas de tempo e custo. De fato, qualquer programa ou projeto de natureza complexa, que abrange um período de tempo prolongado, requer um investimento monetário significativo e tem múltiplos componentes que precisam ser gerenciados simultaneamente, apesar dos esforços heróicos tradicionais de gerenciamento de projetos são vulneráveis. Esta tendência de tais projetos se expandirem além de seus limites iniciais e muito além de suas previsões é chamado de “Scope Creep“.

Neste artigo, examinamos esse fenômeno, vendo grandes projetos como sistemas complexos. Ao entender o scope creep neste contexto, podemos começar a identificar como e por que ele ocorre. Equipados com esse conhecimento, pessoas capacitadas, equipes e organizações podem planejar e mitigar com mais eficácia os efeitos do aumento do escopo, adotando uma perspectiva mais realista e dinâmica sobre o processo de gerenciamento de projetos.

A Dinâmica do aumento de escopo

Como começa o scope creep e o que faz com que ele construa sobre si mesmo ao longo do tempo, levando a excessos e atrasos dispendiosos?

As organizações iniciam projetos para lidar com uma necessidade percebida (veja “A Dinâmica do Scope Creep” na figura 1). Por exemplo, a cidade mencionada acima enfrentou escassez periódica de água durante os períodos de seca, por isso decidiu construir um reservatório para atender suas necessidades de água percebida. Em um mundo ideal, após algum atraso, o projeto seria concluído dentro do seu orçamento original e no cronograma, e a necessidade percebida seria preenchida (B1).

O montante 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 forem envolvidas, mais complexa será a governança. Por exemplo, em uma empresa de TI, um esforço de desenvolvimento de produtos em grande escala requer a entrada de uma série de departamentos, cada um com sua própria gestão e suas próprias prioridades. Vários subprojetos de esforço maior poderiam acabar competindo uns com os outros pelas habilidades de testadores, programadores de banco de dados ou analistas de negócio, tornando complexa a governança global. A competição por recursos limitados se intensifica à medida que o número de subprojetos se expande, tornando a gestão do esforço geral mais desafiadora.

Quando a governança é complexa, os gerentes acham difícil tomar decisões em tempo hábil e atender às conseqüências a longo prazo de cada decisão. Essas dificuldades ameaçam a precisão das estimativas de cronograma. A medida que os prazos se aproximam e a pressão do tempo aumenta, as pessoas tendem a “aparar arestas” para manter o projeto em andamento. Em um projeto de desenvolvimento de software, por exemplo, aparar arestas freqüentemente significa desenvolvimento paralelo inadequado – talvez desenvolvendo aplicativos que dependem de módulos de nível inferior antes que estes módulos sejam totalmente projetados. Aparar arestas em um projeto de construção poderia significar aceitar a menor oferta sem qualificar o fornecedor, não permitindo tempo suficiente para coordenar o trabalho dos vários subcontratados, ou mesmo negligenciar e deixar o cimento curar corretamente. No curto prazo, a apara de arestas pode aparecer para aliviar pressões de programação (B2), mas na verdade é um exemplo do clássico “Conserte essa falha“. Em um cenário “Conserte essa falha” uma ação que resolve um problema no curto prazo realmente exacerba a mesma condição no longo prazo. Assim, ao longo do tempo, as arestas aparadas geralmente resultam em retrabalho, o que inevitavelmente cria ainda mais pressão de programação (R3).

Retrabalho também aumenta o custo, a medida que o custo de um projeto aumenta, os gerentes de projeto precisam justificar as despesas adicionais para a alta direção ou para os seus constituintes. Para fazer isso, eles muitas vezes se encontram prometendo recursos novos e aprimorados para tornar a despesa adicional mais palatável. Por exemplo, um funcionário eleito pode dizer a um grupo de stakeholders nervosos: “É claro que uma represa custando este valor vai incluir uma área de recreação.” Ou os stakeholders podem decidir que uma empresa com valor alto deva incluir uma área de recreação e fazem pressão para que seus funcionários adicionem o mesmo. As expectativas de um projeto de TI podem aumentar quando o departamento de vendas garante aos clientes insatisfeitos, “Oh, temos um novo lançamento em desenvolvimento que abordará sua preocupação.” As garantias e suposições como essas aumentam as expectativas dos clientes e expandem o escopo do projeto (R4).

Em nota pessoal já trabalhei em projetos onde o comercial prometeu “[…Teremos o sistema de cotação ao vivo, online e com videoconferencia dentro deste projeto, já está em fase de testes…]”

Mas ninguém avisou a empresa que essa funcionalidade deveria existir!

Conforme o escopo do projeto aumenta, a rede de interações e dependências entre tarefas, subprojetos, departamentos e agências se torna ainda mais intrincada. Esta crescente complexidade pode levar a atrasos. Por exemplo, em um projeto de construção, se um subempreiteiro tem que esperar por um segundo empreiteiro para terminar suas tarefas, ele pode assumir um outro trabalho. Ele então não pode ter o pessoal imediatamente disponível para trabalhar no projeto original quando o primeiro subcontratado está finalmente pronto para ele. O atraso cria ainda mais pressão no prazo e reforça a “dinâmica do escopo”.

Essas interações e dependências também tornam difícil estimar com precisão os custos. Os atrasos podem agravar ainda mais o problema, tornando as estimativas de custos ainda menos precisas. Se os custos reais são muito mais altos do que as estimativas iniciais, se a pressão sobre os funcionários e gerentes para justificar os custos aumenta, a demanda acaba por influenciar ainda mais as expectativas do projeto e causar ainda mais Scope Creep (R5).

A complexidade da Governança afeta mais do que a pontualidade das decisões. Isso também afeta a capacidade dos tomadores de decisão para ver os efeitos de suas decisões – tanto em outros aspectos do projeto e mais tarde no tempo. Com menos visibilidade dos efeitos a jusante, 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 para aumentar o escopo encontra suas raízes em duas suposições subjacentes. A primeira é que podemos gerenciar um projeto simplesmente gerenciando suas partes. Esta prática leva-nos a ignorar o impacto global de decisões locais aparentemente pequenas, que por sua vez podem minar as estimativas iniciais de tempo e de custo e aumentar a complexidade do projeto. A segunda é que nós assumimos que podemos estimar cronograma e custos com precisão antes de iniciar o trabalho. Mas muitas vezes, quando um projeto custa mais ou demora mais tempo do que o esperado, respondemos assumindo que ele deve incluir recursos adicionais ou adicionando mais deliberadamente para justificar o aumento do custo ou o aumento do escopo de composição de tempo.

Além da Gestão Tradicional de Projetos – TPM (Tradicional Project Management)

Até o momento, a maioria das explicações sobre o scope creep decorrem de uma visão linear e seqüencial dos projetos e como eles são gerenciados. Por exemplo, o Project Management Institute define as cinco fases de gerenciamento de projetos como Iniciação, Planejamento, Execução, Monitoramento e Contole e Encerramento – o Guia PMBOK®2 Este modelo pressupõe que uma fase é completada antes da próxima começar e que devemos retornar às fases anteriores somente quando ocorrerem problemas.

Usando este quadro seqüencial, vários autores escreveram que o scope creep ocorre quando a fase de planejamento é incompleta. Por exemplo, alguns sugerem que se os objetivos e os “deliverables” do projeto não forem totalmente definidos no início ou se os critérios de trabalho não forem claros, então o projeto excederá suas projeções originais de custo e cronograma. Outros atribuem ao scope creep a necessidade de recursos mal definidos ou financiamento insuficiente. Outro conjunto de explicações foca os problemas que ocorrem durante a fase de monitoramento e controle; Por exemplo, mudanças mal documentadas nas especificações do projeto.

Todas estas explicações são provavelmente corretas até certo ponto. No entanto, mesmo se uma equipe rígida adere a esta estrutura de gerenciamento de projeto e conclui cada passo com quase perfeição, scope creep ainda pode ocorrer, especialmente em projetos grandes e complexos. Bom, gerenciamento de projeto linear é necessário. No entanto, como a freqüência de aumento do escopo mostra, é insuficiente para evitar o problema.

A desvantagem do modelo tradicional de gerenciamento de projetos é que ele não conta adequadamente o fato de que um grande projeto – como a construção de um reservatório, o desenvolvimento de um grande e complexo software ou a redação de um grande currículo de treinamento – é realmente um grande sistema com múltiplas partes interagindo. De acordo com o professor John Sterman do MIT, “Os projetos em grande escala pertencem à classe de sistemas dinâmicos complexos. Esses sistemas (1) são altamente complexos, consistindo em múltiplos componentes interdependentes, (2) são altamente dinâmicos, (3) envolvem múltiplos processos de feedback, (4) envolvem relações não-lineares e (5) lineares de dados”3

Ao descrever problemas nesses tipos de sistemas, a autora Meg Wheatley diz: “Eles não podem ser suficientemente compreendidos antes ou mesmo enquanto estão ocorrendo; Portanto, a previsão e o controle são impossíveis”4. Em outras palavras, as interações entre as tarefas, os subprojetos e as estruturas de governança de um projeto complexo tornam quase impossível definir totalmente os resultados do projeto ou entender os requisitos de recursos com antecedência.

A Dinâmica do Scope Creep

scope-creep-dinamica-custo

Um projeto grande e complexo envolve mais do que uma série de tarefas a serem cumpridas: envolve pessoas em uma estrutura organizacional fazendo o trabalho, o que inclui tomada de decisão, governança e previsões de tempo e custo. Cada um desses aspectos do projeto tem um impacto sobre os outros, agregando complexidade dinâmica ao processo e afetando as expectativas das pessoas.

Por exemplo, no desenvolvimento de software, os gerentes normalmente dividem projetos em vários módulos – cada um deles deve ser projetado e desenvolvido de forma independente e, em seguida, combinado em um produto concluído. Eles então quebram o trabalho em cada módulo em uma série de tarefas, que podem ser seqüenciadas e colocadas em uma linha do tempo. Parece lógico pensar que se essas tarefas forem cumpridas da maneira prescrita, sua conclusão deve constituir o projeto total. Na prática, porém, o grau de interdependência entre os módulos geralmente não se torna plenamente evidente até depois que as equipes já investiram muito esforço em design e desenvolvimento. Nesse ponto, os componentes freqüentemente requerem mais design, codificação e teste do que o originalmente orçamentado para fazer os módulos trabalharem 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 do projeto não – porque as pessoas envolvidas podem obter novas idéias sobre o que o produto deve oferecer. Por exemplo, um projeto de software que começou como uma reescrita de código para corrigir um problema evolui quando os projetistas percebem que resolver o problema torna mais fácil implementar uma solicitação de cliente que foi difícil de implementar no código antigo. Para satisfazer o cliente, eles projetam o pedido na reescrita. Uma única adição como esta normalmente não representa um problema. No entanto, quando uma reescrita é grande e dispendiosa, os gerentes podem ser pressionados a adicionar vários desses pedidos de clientes para justificar a despesa do projeto. A abordagem padrão do gerenciamento de projetos negligencia levar em conta tais mudanças nas expectativas.

Assim, o que começou como uma correção simples inesperadamente pode se tornar um grande projeto para atender às demandas dos clientes.

A Dinâmica do aumento da complexidade

scope-creep-complexity

Se uma cidade optar por adicionar uma área recreativa a um projeto de barragem, pode parecer lógico pensar que o escopo do que tem de ser gerenciado aumenta em 33%.Na verdade, adicionando apenas mais um componente, a cidade duplicou o número de interações entre os diferentes componentes – passando de seis para 12.

Sterman identifica dois tipos de complexidade em projetos: combinatório e dinâmico. A complexidade combinatória é criada pelas atividades paralelas e seqüenciais que ocorrem em um projeto grande e complexo – por exemplo, em um grande projeto de construção, todas as licenças são necessárias antes de quebrar o solo. Ferramentas de gerenciamento de projetos tradicionais, como 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 grande projeto. Como as interações entre múltiplas variáveis ao longo do tempo geram esse tipo de complexidade, elas podem crescer geometricamente ou até exponencialmente à medida que elementos adicionais entram no sistema (veja na imagem acima). Por exemplo, a visão tradicional sustenta que adicionar uma quarta tarefa a três que já estão agendadas aumentaria a carga de trabalho proporcionalmente, ou seja, 33%. No entanto, este cálculo não leva em conta o fato de que a nova tarefa interage com cada uma das tarefas existentes, na verdade, dobrando as interações entre tarefas e potencialmente aumentando a quantidade de trabalho por muito mais de um terço. Por esta razão, a complexidade dinâmica contribui significativamente para o fenômeno de fluência de escopo e não pode ser adequadamente abordada usando abordagens lineares padrão.

Mitigando o scope creep

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

Complexidade dinâmica de superfície – A primeira chave para mitigar o scope creep é encontrar maneiras para a superfície de processos de feedback, os atrasos e as relações não-lineares em um projeto grande e complexo. Aqui estão algumas sugestões:

  • John Sterman demonstrou o valor de usar modelagem de dinâmica de sistemas em projetos de grande escala em conjunto com ferramentas tradicionais. Esta abordagem pode ajudar a superar muitas das interações entre tarefas, subprojetos e estruturas de governança que, em última instância, levam ao scope creep e podem tornar explícitas muitas suposições que muitas vezes permanecem não ditas. Com essa informação, os tomadores de decisão e os gerentes de projeto podem tomar decisões mais informados 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 usar um modelo de dinâmica do sistema não for prático, desenhar diagramas de loop causal pode ajudar os gerentes a identificar circuitos 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 do pensamento de sistemas e diagramas causais do laço, os decisores reconhecem frequentemente muitos atalhos como correções que falham. Mas porque é difícil manchar padrões do comportamento ao executar um projeto, os gerentes devem antecipar e documentar o problema potencial das áreas de frente. Uma maneira de fazer isso é identificar quaisquer tipos de sistemas operando em projetos anteriores, documentá-los e compartilhá-los com a equipe do projeto. A equipe então precisa avaliar continuamente se padrões semelhantes estão surgindo no projeto atual e tomar as medidas apropriadas para evitar cair nas mesmas armadilhas. Antecipar essas situações, documentá-las antecipadamente e nomear alguém para denunciá-las se surgirem podem levar a decisões mais inteligentes quando a ação começar em uma iniciativa importante.
  • O processo 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, cultura da organização, práticas de manejo arraigadas e restrições orçamentárias. Devido à complexidade do processo de tomada de decisão, os gerentes de projeto muitas vezes tomam decisões sem levar em conta como elas podem afetar o resto 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 de possíveis resultados na parte superior de uma página. Em seguida, pense nas possíveis soluções em consideração e liste-as no lado 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 atendem aos resultados desejados.
  • O planejamento de cenários oferece outra maneira de identificar e explorar os possíveis resultados – previsíveis e improváveis – das decisões que estão sendo consideradas. Para uma aplicação simples do planejamento de cenários, ver Peter Senge et al5. Durante o processo de planejamento de cenários, os gerentes de projeto e as equipes também podem identificar algumas “correções que falham” adicionais a serem evitadas.

Repensar Abordagens para orçamentos e cronogramas. Nós também precisamos repensar a suposição comum de que podemos fazer previsões precisas de custo e cronograma em um grande projeto. Esta expectativa é irrealista, devido à natureza intrinsecamente mutável de tais projetos. Portanto, precisamos de uma abordagem “escalável” para orçamentos e cronogramas, uma em que regularmente revisamos e atualizamos estimativas de tempo e custo. Tais revisões devem incluir um cronograma para as decisões sobre como continuar com o projeto, escalando-o para trás, ou mesmo cancelando-o. Ao longo do 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 idéia 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 “pontos de fuga”, conforme descrito acima. Essas estimativas e opiniões internas ajudam a evitar que as pessoas se sintam presas e traídas quando grandes projetos vão “aumentando o orçamento” e ficam atrasados.

Use o propósito original como uma âncora. Há uma tendência para usar expectativas atuais como uma espécie de ponto de ancoragem ao considerar mudanças no escopo de um projeto. Esta propensão pode ser perigosa, porque as expectativas atuais podem ter mudado significativamente desde o início do projeto. Na verdade, a dinâmica por trás do scope creep são semelhantes àqueles da estrutura arquetípica de “Drifting Goals”. Em “Drifting Goals”, dois laços de equilíbrio interagem para fazer com que as metas e os padrões diminuam ao longo do tempo. No scope creep, uma série de processos de reforço constantemente “elevam a barra” e impedem o projeto de ser concluído dentro de suas projeções originais. Para ajudar a evitar esse processo, volte para o 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 podem ser as ramificações?

Siga Boas Práticas de Gerenciamento de Projetos. Finalmente, continuar a utilizar boas práticas de gerenciamento de projeto. Muitas ferramentas tradicionais permanecem 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 é muitas vezes citado como dizendo: “Os problemas significativos que enfrentamos não podem ser resolvidos no mesmo nível de pensamento que estávamos quando os criamos.” Scope creep é um problema. Até à data, a maioria das tentativas para controlar o scope creep tem sido linear, a lógica aditiva para neutralizar o que é um fenômeno altamente complexo, dinâmico. Esta maneira seqüencial de pensar coloca a culpa pelo scope creep em práticas de gerenciamento de projetos pobres. Mas ao invés 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, ofereço abordagens que não são visíveis a partir da abordagem linear tradicional. Acredito que essas idéias podem servir como oportunidades de aprendizagem e como sementes para outras soluções. Aprender a ver grandes projetos como sistemas complexos pode não ser uma revolução, mas pensamos que é um primeiro passo digno para uma possível e necessária evolução na forma como as organizações operam. No final estamos perdidos em normas e standards e nos esquecemos que o híbrido pode auxiliar de forma não-linear de pensamento

PRÓXIMOS PASSOS

  • Circule este artigo entre os membros de sua equipe de projeto e discuta como os conceitos podem se aplicar ao seu trabalho. Pergunte: “Quais as idéias do artigo que mais chamaram seu interesse?” “Havia alguma parte do artigo que soou especialmente verdade para nós?” “Como pensar sobre nosso projeto como um sistema complexo nos ajuda a tomar melhores decisões de longo prazo ? “
  • Faça uma lista de atalhos que você pode tomar (ou ter tomado) em seu projeto para mantê-lo dentro do cronograma. Quais poderiam ser alguns efeitos indesejáveis a longo prazo desses atalhos?
  • Crie um diagrama causal de laço que capture as relações entre os vários aspectos de seu projeto. Use este exercício para expor e desafiar suposições sobre como os elementos de seu projeto afetam uns aos outros
  • Documentar a finalidade do projeto e o que se espera que ele atinja, e perguntar se as expectativas se expandiram durante revisões regulares.
  • Nomear um “historiador” para extrair dados de projetos anteriores, identificando padrões de comportamento ou arquétipos que levaram a problemas. Educar a equipe do projeto nessas áreas problemáticas para que todos possam observar padrões semelhantes no projeto atual

Referencias

  1. https://pt.wikipedia.org/wiki/Cyril_Northcote_Parkinson  
  2. Guia PMBOK® – http://www.pmi.org/pmbok-guide-standards/foundational/pmbok  
  3. “System Dynamics Modeling for Project Management”, seção 3, página 5, http://jsterman.scripts.mit.edu/  
  4. THE SYSTEMS THINKER, V9N10  
  5. The Dance of Change: The Challenges to Sustent Momentum in Learning Organizations (Doubleday, 1999), pp. 187-190  

Comentários

comentarios

Coimbra, PMP on sabbehanceCoimbra, PMP on sabfacebookCoimbra, PMP on sablinkedinCoimbra, PMP on sabyoutube
Coimbra, PMP
Gerente de Projetos, PMO, CEO do portal Projetos e TI, Professor de Pós/MBA e apaixonado por gestão de projetos.

Coimbra, PMP

Gerente de Projetos, PMO, CEO do portal Projetos e TI, Professor de Pós/MBA e apaixonado por gestão de projetos.