scope creep

Existem várias personagens (ou intervenientes) num projecto: a equipa de projecto (onde se encontra o gestor de projectos), key users, sponsor, outros stakeholders, etc.

Agora se imaginarem um projecto como sendo uma história da Disney, existem sempre “os bons” e “os maus”. Ora se “os bons” são todos estes que acabei de referir, “o mau” (o vilão) é sem dúvida nenhuma o scope creep.

O scope creep é a pessoa que basicamente passa o tempo todo a tentar alterar o âmbito acordado e a forçar a inclusão de novas features sem mexer no prazo e no custo. Soa-vos a alguém familiar? É muito provável que sim, pois todas as histórias (neste caso projectos) têm sempre um vilão.

A sorte é que em todas as histórias existe sempre alguém (um herói a.k.a. “o bom”) que faz frente ao mau e que geralmente leva sempre a melhor. Inclusivamente muitos deles fazem parte da nossa infância: o batman, o spiderman, o capitão américa, o hulk, etc.

Num projecto quem costuma ser o herói que tenta salvar o mundo (projecto) do scope creep?

Adivinharam! É o gestor de projectos!

O project manager apesar de não ter capa, de não andar com as cuecas por fora das calças e de não ter propriamente poderes sobrenaturais, deve a todo e qualquer momento lutar intransigentemente pelos interesses do projecto, o que implica “derrotar” o scope creep.

E como?

Blindando a equipa de projecto de todo e qualquer contacto com o scope creep e relembrando constantemente ao vilão o âmbito acordado do projecto.

Não quer dizer com isto que alterações ao âmbito do projecto sejam de evitar. As mudanças devem ser encaradas com naturalidade e são de salutar. O que não é de todo de saudar é alterações de ultima hora, “em cima do joelho”, sem medirmos o real impacto no projecto e comunicadas de forma pouco clara e pouco oficial. E é desta forma que um scope creep tenta alterar o âmbito de um projecto. A tentar incluir uma pequena alteração aqui, uma pequena feature acolá, destruindo aos poucos toda e qualquer hipótese do projecto ser bem sucedido.

Atenção aos scope creeps. Eles andam por aí! A sorte é que temos sempre um super herói para salvar o dia. 🙂

Até para a semana.

Nota: Scope creep pode também ser definido como o fenómeno de alterar o âmbito e não como a pessoa que tenta provocar a alteração.

Anúncios

gestão do âmbito

Antes de mais peço desculpa por não ter escrito a semana passada mas a verdade é que estive envolvido num processo de mudança de casa e como tal não tive acesso ao bem precioso que é a internet.

Agora sobre o tema desta semana, o âmbito é “algo” que é definido no início de um projecto. E ao contrário do que seria de esperar, o âmbito é tão instável que é normal ser alterado durante o ciclo de vida de um projecto.

E como se procede a essa alteração? Antes de mais através da formalização da comunicação alteração do âmbito por parte do sponsor ou stakeholder responsável. A partir deste ponto devemos avaliar junto do arquitecto/líder técnico ou junto da equipa que impactos esta alteração trás ao nosso planeamento:

  • É exequível?

  • Precisamos de mais tempo?

  • Precisamos de mais recursos?

  • O que foi desenvolvido até à data é posto em causa?

  • Toda a equipa tem disponibilidade para levar o projecto até ao fim? (Imaginemos que precisamos de mais tempo para o projecto e um recurso já está escalado para outro projecto no próximo mês)

  • Como minimizamos o impacto no nosso projecto?

  • O âmbito é negociável?

  • Podemos abdicar de alguma feature para cumprir com o novo âmbito?

São várias as questões que o gestor de projecto deve colocar. Deve não só procurar a resposta para todas como acima de tudo revelar muita calma, confiança e segurança à equipa de forma a evitar resistências à mudança. A equipa deve assumir o novo âmbito como um desafio e não como uma contrariedade.

Depois do plano de acção estar refeito, o gestor de projecto deve comunicar as alterações de âmbito (confirmação do que será desenvolvido durante o resto do projecto), do tempo e dos custos. E como faz isso? Através de um documento de “Change Request” onde irá formalizar todas as alterações de forma a assegurar o compromisso do sponsor ou stakeholder responsável pela mudança do âmbito.

O bottom line aqui é nunca fazer uma tempestade num copo de água por causa de uma alteração de âmbito. O âmbito deve ser o mais estável e preservado possível mas temos de ser realistas o suficiente para aceitar que um projecto em que o âmbito se torna desenquadrado da realidade de uma empresa é um projecto inútil e que irá gerar um produto obsoleto.

Sem dúvida que é frustrante a meio de um projecto ter de re-equacionar todas as variáveis e por vezes ponderar até que ponto o projecto faz sentido ou não… mas se tudo fosse fácil também não era preciso gestores de projectos.

Os imprevistos e problemas existem tanto na vida como num projectos. E enquanto formos gestores de projecto temos como missão assegurar que nenhum deles prejudica o nosso projecto. Isto leva-me a crer que é pena não termos na nossas vidas também um “gestor de projecto”.

Até para a semana.

atrasos

Sem dúvida que o bicho papão de qualquer projecto é o  “atraso”.

E afinal o que são os “atrasos”?

Os atrasos são deslizes no tempo, ou seja, é o resultado da decisão dos stakeholders em abdicar do Tempo em favor da Qualidade e do Custo (de forma a cumprirem com determinadas expectativas).

Esta decisão é um clássico na gestão de projecto e por norma das mais erradas. Isto porque é mais vantajoso cumprir os tempos do projecto e refazer o âmbito (menos funcionalidades, menos relatórios, menos detalhe) mantendo a qualidade e o custo do que pura e simplesmente abdicar do tempo na expectativa de manter o âmbito intacto e que os novos tempos se cumpram sem mais percalços.

Tendo em conta que os “atrasos” acontecem sempre nos projectos, os stakeholders deveriam encarar este fenómeno de outra forma. Não pelo lado negativo mas sim como um acontecimento natural que exige uma reflexão sobre todo o projecto.

E a que se devem os “atrasos”?

Basicamente os atrasos devem-se a todos os stakeholders no geral:

– programadores (atrasarem-se nos desenvolvimentos);

– líder técnico (estimativas erradas);

– gestor de projecto (má orquestração de todas as partes envolvidas no projecto e/ou estimativas erradas);

– outras equipas (é sempre difícil coordenar um projecto em que envolva mais do que 1 equipa, onde cada uma tem o seu objectivo e o seu respectivo calendário);

– decisores (redefinição de requisitos a meio dos desenvolvimentos quer por alterações da realidade quer por omissão de requisitos durante a fase de análise ou até por alteração dos decisores em si);

– sponsor (alteração da prioridade/importância do projecto);

Resumindo, os “atrasos” podem acontecer por culpa de qualquer pessoa ligada ao projecto.

Mas não é só por causa das pessoas que um projecto pode atrasar. Existem outros fenómenos que originam atrasos:

– fenómenos externos à organização (situação actual da economia e decisões políticas);

– tecnologia (tecnologia desadequada ao projecto);

– indisponibilidade dos stakeholders (férias, despedimentos, gravidez);

ou seja, os atrasos podem ser motivados por imensos factores o que faz com que os atrasos em si sejam perfeitamente naturais dentro dos projectos. E sendo uma realidade intrínseca em qualquer projecto, a principal função do gestor de projecto é não só evitar os atrasos mas essencialmente fazer com que qualquer atraso prejudique o menos possível o projecto.

Para me explicar melhor vou dar um exemplo: Imaginem um capitão num barco em alto mar. Apesar de poder optar sempre pelas rotas mais favoráveis, a verdade é que eventualmente vai-se cruzar com uma tempestade. E aí sim é que se vê quem é bom capitão. Bom capitão é aquele que atravessa a tempestade e leva a sua tripulação para um porto seguro. E deve-se dar tanto ou mais valor a quem consegue atravessar uma tempestade do que a quem, por sorte ou mérito, a consegue evitar (a sorte não dura para sempre e nem todos os dias somos brilhantes).

Creio que o assunto “atrasos” está por agora encerrado.

Estamos agora a começar a entrar na gestão da mudança (em atravessar tempestades). Mas sobre esse tema iremos falar no próximo post.

Até para a semana.