Definição do escopo do projeto
Mudanças do escopo
Atualizado em 16.2.2010Consideremos a situação: a gerente de vendas de uma empresa de equipamentos eletrônicos contrata uma agência web para redesenhar seu site de vendas. Explica que precisa de um site dinâmico, com extenso banco de dados, forte apelo visual, processo de compras intuitivo e fórum de atendimento ao cliente. A agência começa o projeto. Depois de algum tempo, a gerente percebe que a página Principal precisa de imagens 3D dos produtos. E o banco de dados não precisa ser grande, pois o catálogo não vai aumentar a curto prazo.
■ Situações como esta são frequentes. A evolução do projeto, somada ao contato entre colaboradores, usuários e patrocinadores, cria demandas por produtos que não faziam parte do escopo inicial, não citados no Termo de Abertura do Projeto.
Através das mudanças do escopo, pode-se adaptar aos poucos o produto às necessidades do negócio, definidas por conjuntos de forças internas e externas não controláveis pelos gestores do projeto.
■ As alterações do escopo podem ocorrer também devido a mudanças exteriores ao projeto, como:
◊ Novas legislações e regulamentos corporativos, que levam à reavaliação das políticas de imagem e comunicações da empresa.
◊ Mudanças nos objetivos estratégicos ou de negócios da organização.
◊ Mudanças gerenciais amplas (trocas de presidentes e diretores).
◊ Mudanças tecnológicas (lançamento e atualização de dispositivos, sistemas, programas, funcionalidades).
■ O impacto das alterações nos processos de trabalho pode ser pequeno e não demandar respostas significativas. Mas pode também levar a alterações estruturais dos planos iniciais, da quantidade de produtos e de trabalho necessário, exigindo a atualização dos requisitos de projeto e/ou dos métodos de criação dos produtos.
As mudanças podem incluir a necessidade de revisão de processos já aprovados, como o design e a programação da interface, conteúdo em diversos formatos, arquitetura da informação. E das estimativas de recursos (pessoas, equipamentos, prazos, orçamento).
Embora tanto os métodos de gestão de projetos ágeis quanto o método em cascata demandem cuidadoso planejamento, os dois métodos lidam com mudanças de maneira radicalmente diferente. Enquanto os gestores tradicionais procuram adaptar os resultados aos planos, em métodos ágeis ações adaptativas procuram indicar as próximas ações, e alterar os planos para a sua realização.
■ O gestor do projeto deve realizar as ações necessárias para fazer frente às mudanças. De modo geral, a gestão das mudanças de escopo inclui:
◊ A divulgação inicial do escopo do projeto, através de documentação ou de 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 estes 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 do 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, na EAP. São compatíveis com as plataformas atuais? Podem levar a novas mudanças? Acrescentam valor e qualidade ao produto final?
◊ A aprovação ou não das mudanças de acordo com a avaliação.
◊ 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.
■ Agências web que realizam projetos para outras organizações, podem também adotar processos como:
◊ Definir na proposta (como observação) o que configura uma mudança de escopo, que se trata de um processo natural em todos os projetos, mas acarreta em aumento do número de horas de desenvolvimento e que precisa ser evidenciada ao longo do trabalho em conjunto, e se necessário, negociada caso a caso.
◊ Dividir o projeto em pequenas 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 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 rápidamente.
◊ Estabelecer, desde a conversa inicial, que o projeto web é orgânico e não se encerrra 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, podem exigir um orçamento suplementar para a produção do novo número de produtos, bem como o número de horas de trabalho a mais que as solicitações demandam.
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 web sites, 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 iniciais.
Para lidar com os aumentos de prazos, o Termo de Abertura pode incluir:
◊ 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 a 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 adotadas, é 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.
Assuntos relacionados
► Ressalvas no escopo ou no contrato
► Abordagens do escopo
► Elementos do Termo de Abertura do Projeto
► Atividades relacionadas (à articulação do escopo)
► Visão geral do escopo - modelo resumido
► Análise estratégica (projeto de web site ≠ estratégia web)
► Desenvolvimento : Mapeamento de processos : Muita resistência das equipes afetadas pelas mudanças tem origem na percepção da mudança, e nâo nos novos processos em si
► Acompanhamento dos processos de produção (verificação de sua aderência a objetivos, prazos, custos do projeto)
► Monitoramento das atividades
► Recursos disponíveis
► Gestão de projetos web - seleção de metodologias
Mais informações sobre o assunto (links externos)
► Adapting over conforming (Projects at Work, acesso em 27.8.2009)
► Loose change (Gantthead, acesso em 29.10.2008)
► Scope freeze (Gantthead, acesso em 29.10.2008)
► Holding the line, de Nick Jenkins (Projects at Work, acesso em 8.12.2007)
► Fine acommodations, de Nick Jenkins (Projects at Work, acesso em 14.5.2007)
► Managing change requests (Projects@Work, 2.7.2006)
► Successful web development methodologies (SitePoint, acesso em 16.4.2006)
► Getting IA done (Digital Web, acesso em 15.6.2006)
► Call and response: Handling RFP tension (Human Factors International, acesso em 31.8.2005)
► Bulletproof web design contracts (SitePoint, acesso em 19.11.2005)