O que é a deriva do âmbito e como geri-la eficazmente

A expansão descontrolada do âmbito pode afetar qualquer projeto com âmbito fixo. Pode ocorrer de forma intencional ou não intencional e ter origem em qualquer interveniente envolvido num projeto. A expansão descontrolada do âmbito pode levar ao fracasso do projeto, fazendo com que não cumpra um prazo, esgote (ou ultrapasse) o orçamento devido a derrapagens de custos e, além disso, continue a entregar a solução errada.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

10 causas comuns da expansão descontrolada do âmbito

A expansão descontrolada do âmbito ocorre normalmente quando os requisitos do projeto não estão claramente definidos, os intervenientes introduzem novos pedidos ou as equipas fazem alterações sem avaliar o seu impacto. Embora a culpa recaia frequentemente sobre os clientes, os gestores de projeto, os membros da equipa e as dependências externas também podem contribuir.

Eis as causas mais comuns da expansão descontrolada do âmbito e o que pode fazer para as prevenir:

• Requisitos pouco claros ou mal documentados: Quando os entregáveis, os limites e os critérios de aceitação não estão claramente definidos, os membros da equipa e os intervenientes fazem suposições diferentes sobre o que está incluído. Crie uma declaração do âmbito do projeto e confirme que todos compreenderam o mesmo antes do início do trabalho.
• Alteração das prioridades dos intervenientes: Os clientes, patrocinadores e intervenientes internos podem solicitar funcionalidades adicionais ou mudar de direção à medida que as prioridades do negócio se alteram. Documente as decisões importantes e avalie de que forma as alterações propostas afetam o calendário, o orçamento e os entregáveis antes de as aprovar.
• Ausência de um processo formal de controlo de alterações: Sem um processo de aprovação claro, pequenos pedidos podem entrar no projeto sem que ninguém avalie o seu impacto acumulado. Estabeleça um processo para apresentar, avaliar, aprovar e documentar alterações ao âmbito. Certifique-se de que todos sabem quem tem autoridade para aprovar.
• Má comunicação e falta de alinhamento da equipa: Os membros da equipa podem tomar decisões de forma independente ou interpretar incorretamente os requisitos, introduzindo trabalho que não estava originalmente planeado. Realize uma reunião de arranque do projeto e reuniões regulares de acompanhamento para clarificar as expectativas e assinalar potenciais alterações.
• Acréscimos desnecessários: Por vezes, os membros da equipa adicionam funcionalidades ou melhorias desnecessárias por acreditarem que irão fornecer um produto melhor. Mesmo os acréscimos bem-intencionados consomem tempo e recursos. Reforce os requisitos acordados e exija aprovação antes de adicionar funcionalidades.
• Estimativas e compromissos irrealistas: Estimativas demasiado otimistas podem levar as equipas a prometer mais do que o orçamento, os recursos ou o calendário conseguem suportar. Envolva as pessoas que irão realizar o trabalho na estimativa do esforço, tenha em conta a incerteza e questione as suposições antes de se comprometer com os entregáveis.
• Envolvimento insuficiente dos intervenientes: Quando os decisores ou os utilizadores finais não estão envolvidos suficientemente cedo, podem surgir requisitos importantes depois do início do desenvolvimento. Identifique os principais intervenientes durante o planeamento e valide os requisitos através de revisões, workshops ou testes com utilizadores antes do início do trabalho principal.
• Dependências de terceiros não geridas: Fornecedores, prestadores de serviços, APIs externas e fornecedores de conteúdos podem introduzir requisitos inesperados ou trabalho adicional. Por exemplo, um fornecedor pode entregar dados num formato incompatível. Identifique as dependências atempadamente, acorde as especificações dos entregáveis e tenha em conta potenciais problemas de integração.
• Gestão de projetos e responsabilização deficientes: Por vezes, os gestores de projeto aceitam trabalho adicional para manter as relações com os clientes ou evitar conversas difíceis. Verifiquei que pequenas concessões não documentadas podem rapidamente transformar-se em expectativas. Acompanhe as alterações, explique o seu impacto e proponha compromissos em vez de absorver trabalho adicional.
• Restrições ou descobertas técnicas inesperadas: Sistemas antigos, limitações de integração ou requisitos técnicos negligenciados podem criar trabalho que não foi previsto durante o planeamento. Realize uma análise técnica atempadamente, valide as principais suposições e distinga o trabalho corretivo necessário das melhorias opcionais antes de alterar o âmbito.

Exemplos de expansão descontrolada do âmbito

A expansão descontrolada do âmbito pode ocorrer quando os intervenientes introduzem novos pedidos ou quando dependências inesperadas criam trabalho adicional. Estes dois exemplos hipotéticos mostram como a expansão descontrolada do âmbito se desenvolve, o seu impacto nos projetos e como lidar com ela.

Exemplo 1: Pedidos das partes interessadas durante os testes com utilizadores

A sua equipa está a realizar testes com utilizadores para um novo protótipo de sítio Web. O cliente aprovou um período de testes de duas semanas com 10 participantes e um orçamento de $5,000.

Após o encerramento dos testes, um executivo sénior solicita uma demonstração autónoma e convida mais cinco partes interessadas. Concorda em acomodá-las sem avaliar formalmente o impacto.

	O que aconteceu
Causa	As partes interessadas adicionais apresentaram comentários após o período de testes acordado.
Impacto	As demonstrações adicionais, as revisões dos comentários e as discussões com as partes interessadas acrescentaram 40 horas de trabalho e atrasaram o projeto em 1,5 semanas.
Resolução	O gestor de projeto documentou os pedidos adicionais e apresentou o respetivo impacto ao cliente. Ambas as partes concordaram em adiar os novos pedidos de funcionalidades para uma fase futura e limitar as revisões adicionais ao âmbito original.
Lição aprendida	Estabeleça prazos claros para o envio de comentários, limites de participantes e requisitos de aprovação. Escale as exceções antes de se comprometer com recursos adicionais.

Exemplo 2: Dependências de terceiros não geridas

Está a gerir um projeto de desenvolvimento de um sítio Web com um orçamento de $100,000 e um prazo de 12 semanas. A sua equipa está a criar a interface utilizando o sistema de retaguarda de outra agência.

O desenvolvimento começa após a aprovação da conceção, mas a agência terceira continua a lançar atualizações do sistema de retaguarda. Estas alterações quebram repetidamente o código da sua equipa, criando retrabalho inesperado.

	O que aconteceu
Causa	A agência terceira efetuou alterações contínuas no sistema de retaguarda sem coordenar os lançamentos com a sua equipa de desenvolvimento.
Impacto	As correções repetidas acrescentaram 200 horas de trabalho não planeado, aumentaram os custos em $20,000 e ameaçaram atrasar a entrega em oito semanas.
Resolução	O gestor de projeto interrompeu o trabalho de desenvolvimento afetado e negociou um calendário de lançamentos partilhado com ambas as agências. O cliente aprovou um pedido de alteração de $10,000 e uma extensão de duas semanas. Ambas as equipas concordaram em congelar a versão do sistema de retaguarda até ao lançamento, evitando mais retrabalho.
Lição aprendida	Identifique atempadamente as dependências externas, acorde calendários de lançamentos e estabeleça um processo de controlo de alterações. Não absorva retrabalho contínuo sem avaliar o seu impacto nos custos e nos prazos do projeto.

Como evitar a expansão descontrolada do âmbito

Eis algumas estratégias para reduzir a probabilidade de o âmbito se expandir nos seus projetos:

• Defina claramente o âmbito do projeto: Faça-o desde o início, idealmente envolvendo a equipa do projeto para obter o seu compromisso. Utilize uma declaração de trabalho para registar o que está incluído e excluído do âmbito. Em seguida, comunique o âmbito aos membros da equipa e às partes interessadas do projeto, incluindo o cliente.
• Elabore estimativas sólidas com base nos requisitos: Para reduzir o risco de estimar incorretamente, envolva toda a equipa, reserve tempo para um período de descoberta que permita determinar o que será criado, utilize um contrato baseado em tempo e materiais (em vez de um preço fixo) e seja menos prescritivo relativamente às funcionalidades que irá criar. Concentre-se nos resultados pretendidos.
• Crie planos de contingência: Reserve uma margem realista de tempo e orçamento para problemas inesperados (por exemplo, problemas técnicos, atrasos de terceiros e retrabalho). Identifique as atividades de alto risco durante o planeamento e prepare opções de recurso. As reservas de contingência ajudam a lidar com trabalho imprevisto sem fazer descarrilar o projeto, mas não devem ser utilizadas para absorver alterações de âmbito não aprovadas.
• Crie um plano de gestão de alterações: Faça-o no início do projeto e utilize-o para definir como irá lidar com as alterações ao âmbito. Se tenciona utilizar pedidos de alteração, detalhe o processo de controlo de alterações que irá seguir.
• Colabore com o cliente: Ao longo da execução do projeto, mostre-lhe o progresso do projeto ou o relatório de estado do projeto, faça iterações e envolva-o durante todo o percurso, para que não haja surpresas.
• Apresente os problemas de forma proativa: Faça-o quando surgirem ou, idealmente, antes de surgirem (desde que tenha encontrado uma solução para resolver o problema!). Utilize um plano de gestão de riscos para documentar o seu processo de gestão de riscos. Mantenha e reveja um registo de riscos que acompanhe os riscos potenciais.
• Estabeleça prioridades para os pedidos recebidos: Certifique-se de que estes pedidos não adicionam inadvertidamente âmbito, duplicam trabalho ou criam funcionalidades adicionais desnecessárias. Envolva a equipa para compreender cada pedido, o seu impacto no orçamento e no prazo do projeto e o resultado esperado para o utilizador, para que possa estabelecer prioridades adequadamente.

Como lidar com a expansão descontrolada do âmbito

Se o seu projeto for vítima da deriva do âmbito (ou se herdou um esforço com um âmbito excessivo), não entre em pânico. Ainda tem a oportunidade de sair dessa situação. 

Eis alguns passos que segui ao assumir um projeto problemático que tinha sido vítima da deriva do âmbito:

• Explique a situação: Explique como chegou à situação atual e quais são os seus planos de recuperação para a resolver. Não vale a pena tentar suavizar a realidade. A situação é a que é.
• Recomende formas de reduzir custos e manter o valor: Isto pode significar dar menos prioridade a determinadas funcionalidades ou fazer cedências relativamente a funcionalidades desejáveis até poder lançar algo rapidamente numa fase posterior. Prepare uma apresentação para o seu cliente que defina claramente as cedências associadas a cada uma das suas abordagens.
• Ajuste a dimensão da equipa: Isto pode significar afastar alguém cujo desempenho esteja abaixo do esperado ou substituir um recurso de custo mais elevado por um recurso de custo mais baixo para poupar no orçamento. É desagradável ter estas conversas, mas a alternativa pode ser perder o cliente, o que teria consequências mais graves.
• Lide com as consequências: Por vezes, endireitar um navio a afundar exige que ponha o orgulho de lado e sacrifique a rentabilidade global do projeto para reparar uma relação valiosa com o cliente. Pode ser necessário trabalhar horas extra para concluir algo mais cedo do que o planeado, como forma de compensação. O essencial é limitar este esforço a uma iniciativa de curto prazo, para que não se torne um mau hábito.

Author's Tip

Por vezes, a deriva do âmbito pode ser benéfica. Em vez de a encarar como um inimigo sorrateiro, pode pensar nela como uma mudança. E a mudança pode ser extremamente benéfica para o produto que está a criar. É a forma como gere essa mudança que afeta o projeto, e não o pedido para a efetuar.

 

Tem de ter cuidado para identificar a situação quando ela acontece, especialmente quando não é óbvia, e comunicá-la antes que avance sem qualquer forma de replaneamento.

Perguntas frequentes sobre a deriva do âmbito

As respostas a algumas das perguntas mais frequentes sobre a deriva do âmbito.

Qual é a diferença entre a deriva do âmbito e a alteração do âmbito?

A deriva do âmbito refere-se a adições não controladas aos requisitos do projeto sem os ajustes correspondentes ao orçamento, ao calendário ou aos recursos. A alteração do âmbito é uma modificação deliberada e documentada, analisada e aprovada através de um processo de controlo de alterações. A principal diferença é a autorização. As alterações do âmbito podem ser necessárias e benéficas, enquanto a deriva do âmbito introduz trabalho não planeado que põe em risco a entrega do projeto.

Como identificar precocemente a deriva do âmbito num projeto?

Procure sinais de alerta, como pedidos de funcionalidades adicionais, alterações não documentadas, listas de tarefas cada vez maiores e trabalho que exceda as estimativas originais. Compare regularmente o progresso do projeto com a linha de base do âmbito aprovada. Recomendo que registe todos os novos pedidos num registo de alterações e os analise durante as reuniões de acompanhamento da equipa. Isto ajuda a detetar pequenas adições antes que provoquem atrasos significativos ou derrapagens orçamentais.

Como lidar com a deriva do âmbito quando um cliente solicita trabalho adicional?

Comece por avaliar de que forma o pedido afeta as entregas, os custos e os prazos do projeto. Explique estes impactos ao seu cliente e apresente opções. Pode propor um pedido formal de alteração, trocar uma entrega existente pelo novo requisito ou adiar o trabalho para uma fase posterior. Seja qual for o acordo alcançado, documente a decisão e atualize o plano do projeto antes de avançar.

Como gerir o âmbito em metodologias ágeis?

Os projetos de desenvolvimento ágil acomodam requisitos em mudança, mas continua a ser necessário controlar a quantidade de trabalho a que a sua equipa se compromete. No Scrum, adicione os novos pedidos à lista de pendências do produto e trabalhe com o responsável pelo produto para lhes dar prioridade com base no valor e no esforço.

Se um novo requisito se tornar prioritário, considere retirar prioridade a outro item em vez de adicionar mais trabalho. Durante o planeamento da iteração, certifique-se de que os compromissos refletem a capacidade da sua equipa.

E agora?

Quer estabelecer contacto com outros gestores de projetos digitais para partilhar recursos e boas práticas? Junte-se à nossa comunidade de membros e obtenha acesso a mais de 100 modelos, amostras e exemplos, além de poder contactar com centenas de outros gestores de projetos digitais no Slack.