Consideremos a situação: a gerente de vendas de uma empresa de equipamentos eletrônicos contrata uma agência digital para redesenhar suas plataformas de varejo online. Precisa de um website e aplicativos móveis com apelo visual, compras intuitivas e atendimento personalizado ao cliente. A agência começa o projeto, mas logo a gerente de vendas percebe que é preciso fazer um vocabulário controlado para evitar perdas de vendas por falta de recuperação de sinônimos nas buscas. O escopo inicial muda, como fica a cadeia de produção?
Situações como esta são sempre presentes. A evolução dos projetos, somada ao contato entre colaboradores, usuários, patrocinadores, clientes, cria demandas por produtos e funcionalidades que não faziam parte do escopo inicial. Alterações do escopo podem ocorrer devido a mudanças externas, como:

Mudanças no mercado (o concorrente lançou um produto novo, os usuários responderam muito bem, e é preciso responder à altura).

Mudanças tecnológicas (lançamento e atualização de dispositivos, sistemas, programas, funcionalidades).

Novas legislações e regulamentos corporativos, que levam à reavaliação das políticas comercial, de imagem, de comunicações da empresa.

Mudanças internas ao projeto podem ser causadas por fatores como:

Novas percepções das demandas do cliente levam a alteração dos requisitos (testes de usabilidade, conversas em diversos canais, pesquisas para o projeto, apontam novas demandas do público em relação ao produto).

Novas percepções do dimensionamento do projeto pela contratante e pela contratada, o que leva à necessidade de complementar os produtos combinados.

Mudanças nos objetivos estratégicos ou de negócios da organização cliente.

Mudanças gerenciais (trocas de presidentes e diretores), que podem ocasionar as mudanças de estratégia.

As mudanças demandam a revisão de produtos do projeto já aprovados, como o design e a programação de bancos de dados, arquitetura da informação, conteúdo produzido em diversos formatos. E a revisão das estimativas de recursos (pessoas, equipamentos, prazos, preço para o cliente final) para completar o produto. O impacto das alterações nos processos de trabalho pode ser pequeno e não demandar respostas significativas. Mas pode levar a alterações estruturais dos planos iniciais, da quantidade de produtos e de trabalho necessário, exigindo a atualização do contrato, dos requisitos de projeto e/ou dos métodos de criação do produto.
Embora tanto os métodos de gestão de projetos ágeis quanto o método em cascata demandem cuidadoso planejamento, os dois lidam com mudanças de maneira diferente. Enquanto os gestores tradicionais procuram relacionar os resultados aos planos iniciais, em métodos ágeis as ações adaptativas procuram indicar as próximas ações, e alteram os planos para a realização.
O gestor do projeto deve realizar as ações necessárias para fazer frente às mudanças, achando um equilíbrio entre o excesso de mudanças e a rigidez na manutenção do escopo inicial. Por meio da incorporação das mudanças do escopo ao longo do projeto, definidas por fatores internos e externos imprevisíveis inicialmente, pode-se adaptar aos poucos o produto às necessidades do negócio.

Em projetos em cascata, a gestão das mudanças de escopo inclui:

A divulgação inicial do escopo do projeto, através de documentação ou reunião presencial. O estabelecimento de consenso entre stakeholders tem um efeito moderador para as futuras negociações de mudança de escopo.

A formalização e a justificativa dos pedidos de mudanças, especialmente se foram feitos em ocasiões informais, em trocas de emails e conversas casuais.

A indicação dos responsáveis pelas mudanças, sem intenção de premiá-los pelos bons resultados ou de culpabilizá-los pelos maus resultados. A responsabilização visa a levar os colaboradores a refletir sobre as implicações das suas sugestões e de seu efeito perante os demais participantes do projeto.

A avaliação das consequências das mudanças no cronograma, no orçamento, nos requisitos de qualidade, nos produtos. São compatíveis com as plataformas atuais? Podem levar a novas mudanças? Acrescentam valor e qualidade ao produto final? Compensam os acréscimos de tempo, preço, a mudança de foco da equipe e o tempo e o esforço da própria avaliação das mudanças?

A aprovação ou não das mudanças de acordo com a avaliação. Mudanças pequenas não implicam em mudanças de escopo; se aparece um problema em um botão, por exemplo, não significa que o projeto todo precisará ser refeito.

A homologação e disseminação, entre os stakeholders, das mudanças aceitas. Neste caso, é importante também revisar o plano de projeto interna e externamente (se o projeto inclui fornecedores externos).

A implementação das mudanças nas áreas de gestão e desenvolvimento.

É comum a verificação de que a ideia inicial trazida pelo cliente, e sobre a qual uma equipe inteira trabalhou durante um tempo, não atenda as necessidades dos usuários no final das contas. Pode haver grande perda de recursos avaliando o motivo. Com a maior participação de equipes interdisciplinares – de negócios, de design, de desenvolvimento, de testes, de marketing – nos processos de decisão, pode-se chegar a resultados a partir de iterações dinâmicas sobre o resultado, com mudanças incorporadas ao processo de trabalho diário.

Processos ágeis para lidar com mudanças incluem:

Definir o escopo com o cliente, deixando claras as prioridades e o que configura uma mudança de escopo, e como fazer frente ao a essas mudanças.

Dividir o projeto em pequenos ciclos, em que se desenvolva o produto incrementalmente, cada um com orçamento e estimativa de número de horas próprios, de modo a ir adaptando gradualmente o escopo ao produto. Usado especialmente em métodos ágeis.

Incluir na proposta de trabalho um valor pré-estimado para a contabilização das horas de mudanças de escopo (10% a mais, por exemplo, ou um número de horas determinado), de modo a absorver naturalmente as mudanças mais suaves.

Incluir na proposta de trabalho o valor da hora adicional de desenvolvimento, para contabilizar as horas formalizadas como mudança de escopo. Se o projeto implica na contratação de outras empresas de desenvolvimento, é importante verificar com estas empresas o valor das mudanças, para que sejam realizadas e negociadas mais rapidamente.

Estabelecer, desde a conversa inicial, que o projeto é orgânico e não se encerra no lançamento/ publicação do veículo. Por isto pode-se prever etapas pós-lançamento para a realização de mudanças de escopo e ajustes no produto de acordo com a recepção do público (considerando os dados das estatísticas de acesso, vendas e contatos estabelecidos).

Demarcação de horizontes

Lidar com mudanças deve ser parte dos processos do projeto. No entanto, demanda a previsão de orçamento adaptável a novas situações e ao número de horas de trabalho adicionais necessárias. O prazo de entrega dos produtos nas diversas etapas também faz parte do escopo do projeto, e na verdade, é um dos fatores mais sujeitos a mudanças em projetos de websites, na medida em que no início não se pode saber com absoluta certeza a duração de algumas tarefas. Atrasos muito longos na entrega de informações de projeto ou conteúdo (textos e imagens para a edição das páginas do site), dificuldades de reunir os gerentes para aprovar um produto ou tomar decisões, demoras para liberar recursos, estão entre os fatores que levam à redefinição dos prazos e orçamentos iniciais. Para lidar com os aumentos de prazos, o Termo de Abertura pode incluir:

Processos ágeis, com a liberação de produtos incrementais que incorporem as mudanças ao próprio modelo de elaboração.

Em caso de projetos desenvolvidos com método em cascata, pode-se estabelecer uma data-limite para a entrega do material (conteúdo, equipamentos, programas), que, ao ser ultrapassada, configura uma situação de rompimento de contrato que leva as partes a rever os acertos comerciais.

Pagamento adicional ao tempo excedido em caso de atraso na entrega de conteúdo (neste caso, não ocorre o rompimento do contrato e o aumento do valor financeiro do produto estimula a entrega das informações no prazo combinado).

Prazo-limite para o projeto, depois do qual o pagamento será realizado, independentemente do trabalho estar completo ou não. Neste caso, a finalização terá valores renegociados.

Em muitos casos, é possível remanejar as tarefas em caso de atrasos em processos críticos e atenuar sua repercussão. Mas há situações em que é necessário aumentar a equipe para acelerar o desenvolvimento. Ou realizar em paralelo tarefas previstas para ocorrer em sequência. Sejam quais forem as medidas e métodos de gestão adotados, é importante que as partes envolvidas avaliem os riscos, documentem-nos na estrutura geral de tarefas, avaliem a abrangência e as consequências dos imprevistos. Se as mudanças comprometem muito o escopo do projeto, é preciso ajustar os objetivos e os recursos para realizá-las. (Atualizado em 18.1.2017)

Referências

Keeping scope controlled, Bart Gerardi (Project Management, acesso em 15.10.2014) The hidden costs of change, Bart Gerardi (Projects@Work, acesso em 10.7.2014) The curse of knowledge, Craig Curran-Morton (Gantthead, acesso em 4.11.2011) Project transformers (Projects@Work, acesso em 19.6.2010)