Mudanças

Um dos maiores issues que muitos Gerentes de Projeto têm é a capacidade de dizer não, ou pelo menos é isso que gostariam de dizer quando lhes são solicitados para adicionar mais requisitos para o projeto. Isso claro, depende da organização. Os Gerentes de Projeto que dizem não, geralmente não são vistos como membros da equipe e podem desenvolver rapidamente uma reputação de não cooperativos.

Em alguns projetos, pode haver pressa para iniciar o projeto e, assim, a quantidade de tempo necessária para definir os requisitos e Descrições de Produtos não é utilizada e, como consequencia, o orçamento ERRADO é definido para o projeto. Mais tarde uma funcionalidade aparentemente adicional deve ser incluída e o Gerente de Projetos precisa saber como lidar com essa situação. Está pronto e criado um ambiente propício para o fenômeno chamado por Ernani Marques (linkedin) como Propagação de Erros em Projetos.

Uma das coisas que gostamos bastante no Tema Mudança é que ele mostra a você, na qualidade de Gerente de Projeto, que você não tem que dizer Não ou Sim; mas quando solicitado a adicionar uma nova funcionalidade, você pode até mesmo agradecer a pessoa por sugerir a alteração, e então lhe fornecer um formulário de Solicitação de Mudanças para preencher e oferecer sua ajuda se necessário. Você, em seguida, promete dar seguimento a essa Solicitação de Mudança, e deixa claro ao solicitante que quem vai decidir sobre essa solicitação será a Autoridade de Mudança ou o Comitê Diretor do Projeto.

O Tema Mudanças também descreve os papéis e responsabilidades do Executivo e do Comitê Diretor do Projeto; Isso é útil, pois talvez você precise lembrar o executivo disso. É fácil encontrar projetos onde o Executivo é a própria pessoa que coloca pressão sobre o Gerente de Projeto para permitir mudanças influenciem o projeto, sem fornecer recursos adicionais. Assim, este tema irá mostrar-lhe como lidar com estas situações.

A maioria dos Gerentes de Projeto também estão cientes de que necessitam cuidar dos produtos produzidos pelo projeto; isso é chamado de Gerenciamento de Configuração. Isso envolve principalmente o rastreamento de Mudanças, certificar-se de que as pessoas corretas têm acesso às últimas versões dos documentos de linha de base e proporcionando um local de armazenamento central e acessível. Algumas empresas fornecem um sistema de documentação de TI de fácil uso o que torna mais fácil para o Gerente de Projeto gerenciar, controlar e distribuir informações do projeto. Outras empresas fornecem sistemas que são muito difíceis de usar e, portanto, acabam não sendo usados. A boa notícia é que é muito simples de se obter um sistema online de fácil utilização que irá fornecer a maioria das funcionalidades necessárias, incluindo a proteção de acesso à informação.

O último ponto antes de seguirmos é que a maioria dos Gerentes de Projeto não planejam qualquer tempo para atividades de Gerenciamento de Configuração e acreditam que isso é algo que podem fazer numa tardezinha, ou talvez, enquanto está em uma conferência telefônica….. Cuidado!!!! É uma idéia muito boa planejar este trabalho.

Propósito

O propósito do conhecimento no Tema Mudanças destina-se a ajudá-lo a identificar, avaliar e controlar qualquer mudança potencial dos produtos que já foram aprovados em relação à linha de base. O Tema Mudanças não trata apenas sobre solicitação de mudanças, mas é também sobre o tratamento de issues que surgem durante o projeto. Na verdade, é melhor dizer que o Tema Mudanças oferece uma abordagem comum para Issue e Controle de Mudanças.

A mudança é inevitável em qualquer projeto e todos os projetos precisam de uma boa abordagem para identificar, avaliar e controlar os issues que podem resultar em mudança. Este tema fornece uma abordagem para Issue e Mudanças.

Afinação

O Controle de Issues e de Mudancas acontece durante todo o ciclo de vida do projeto. Lembre-se, o objetivo não é impedir mudanças, mas para obter mudanças acordadas e aprovadas antes de serem executadas.

Cada projeto requer um Sistema de Gerenciamento de Configuração que rastreia os produtos e registra quando os produtos são aprovados e linha de base efetuada; e ajuda a garantir que as versões corretas estão sendo utilizadas durante o projeto e entregues ao cliente.

Definições

Gerenciamento de Configuração

Gerenciamento de configuração é a atividade técnica e administrativa referente à criação, à manutenção e às mudanças controladas da configuração de um produto. Esta é uma maneira agradável de dizer que a Gerenciamento de Configuração é está relacionado a cuidar dos produtos do projeto.

Item de configuração

Um item de configuração é o nome dado a uma entidade (ou item) que é gerenciado pelo Gerenciamento de Configuração.

Você também poderia dizer que um Item de Configuração é qualquer coisa que você deseja rastrear durante o projeto.

Release

Um Release é um conjunto completo e coerente de produtos que são gerenciados, testados e implantados como uma única entidade para ser entregue aos usuários. Um exemplo de uma Release poderia ser uma nova versão de um Notebook com uma certa versão de Sistema Operacional (OS), CPU específico, BIOS específico e certas versões de aplicativos.

Issues

O PRINCE2 usa o termo Issue para cobrir qualquer evento relevante que aconteceu, que não foi planejado e que requer alguma ação de gerenciamento (por exemplo, um questionamento ou uma requisição de mudança). As Issues podem ser geradas a qualquer momento durante o projeto e por qualquer pessoa.

Existem 3 tipos de issues; elas são:

• Definição de Requisição de Mudança : Proposta para uma mudança em um linha de base de um produto, ou seja, um produto que já foi aprovado. Isso pode ser um documento de Descrição de Produtos para um dos produtos do especialista que estão sendo criados pelo projeto.Exemplo: Uma parte interessada solicita para dar suporte a uma nova língua.
• Definição de Não Conformidade : Isso é algo que foi acordado para ser feito, mas não é fornecido pelo fornecedor e/ou não deverá ser fornecido, e portanto, está fora de especificação ou em Não Conformidade. Exemplo: O fornecedor não conseguiu completar o recurso automático de Esqueci a Senha; Portanto a senha terá de ser redefinida manualmente pelo administrador central.
• Definição Problema/Preocupação : Definição: Qualquer outra issue que o Gerente de Projeto precisa resolver ou escalar; Isso pode ser positivo ou negativo.Exemplo: Um membro da equipe foi retirado o projeto durante uma semana.

A abordagem do PRINCE2 para Mudanças

A abordagem de issue e Gerenciamento Mudança será decidida no primeiro estágio (Estágio de Iniciação). Essa abordagem pode ser revista no final de cada estágio do processo Stage Boundary.

O PRINCE2 tem seis produtos de gerenciamento que são usados para controlar issues, mudanças e Gerenciamento de Configuração.

• A Estratégia de Gerenciamento de Configuração : Este documento contém a estratégia sobre como serão tratadas issues e mudanças no projeto (por exemplo, como identificar os produtos, como controlar produtos, como fazer a Descrição de Status e Verificação).
• Registros de itens de Configuração : Eles fornecem um conjunto de dados para cada produto utilizado no projeto (como metadados). (Por exemplo: A mesa central da biblioteca teria um cartão para cada livro com informações específicas, incluindo localização, classificação, número de ISBN, etc).
• Descriçao do Status do Produto : Este é um relatório sobre o estado dos produtos (por exemplo, status da lista de todos os produtos produzidos pelo fornecedor X no estágio 3).
• Diário do Projeto : Esse log é usado pelo Gerente do Projeto como um Diário para toda a informação informal. Informação formal é colocada num registro (Registro de Issue ou Registro de Risco).
• Registro de issues : Imagine uma planilha para registrar e manter issues (formal).
• Relatório de Issues : Este relatório descreve uma issue em detalhes. De acordo com PRINCE2, uma issue pode ser 1) Requisição de Mudança, 2) uma Não conformidade, ou 3) problema/preocupação. Um relatório de issues também poderia descrever issues relacionadas, de modo que não seria sempre um risco.

Estratégia de Gerenciamento de Configuração

O documento de Estratégia de Gerenciamento de Configuração contém a estratégia de como serão tratadas as issues e mudanças no projeto. Uma das primeiras perguntas que o Gerente de Projeto deve fazer é: Quais são os padrões existentes na empresa para Issue e Controle de Mudanças?

Se o projeto estiver em um ambiente de Programa, normalmente haverá um modelo de Estratégia de Gerenciamento de Configuração disponível. A Estratégia de Gerenciamento de Configuração deve responder às seguintes perguntas:

• Como devem ser identificados e controlados os produtos? (Gerenciamento de Configuração)
• Como são tratadas as Issues e Mudanças? (CEPDI)
• Quais ferramentas que serão usadas para ajudar a rastrear issues e informações sobre o produto (por exemplo, SharePoint, Niku Clarity, Drive Compartilhado, uma Planilha)?
• Quais dados devem ser mantidos para cada produto (por exemplo, Registros de Itens de Configuração)?
• Com que frequência o Gerente do Projeto avaliará os Controles de Issue & de Mudança (por exemplo, uma vez por semana, duas vezes um mês, etc.)?
• Quem será responsável pelo quê? Em outras palavras, quais serão os Papéis & Responsabilidades? (Por exemplo, que tem o Papel de Autoridade de Mudanças?)
• Como as issues e mudanças são priorizadas? Que escala será usada para priorizar issues?
• Que escala será usada para a gravidade das issues (por exemplo: 1 a 4, baixo-médio-alto…)?
• Quais os níveis de gerenciamento vão lidar com issues de diferentes gravidades? (Por exemplo: issue de gravidade 1 poderia ser o Gerente do Projeto, mas gravidade 3 e 4 teria que ser para a Autoridade de Mudanças).

Assim como os outros 3 documentos de estratégia, o documento de Estratégia de Gerenciamento de Configuração é criado no estágio de iniciação no processo Initiating a Project pelo Gerente do Projeto e será aprovado pelo Comitê do Projeto.

Priorizar as issues

Há muitas maneiras de priorizar uma Requisição de Mudança e o PRINCE2 introduz a simples técnica MoSCoW para ajudar com isso. As iniciais de MoSCoW são, Must have (Deve ocorrer), Should have (Deveria Ocorrer), Could have(Poderia ocorrer) and Won’t have for now (Não ocorrerá- por enquanto). Veja maiores detalhes:

• Must have (Deve ocorrer) : A mudança é essencial para a vaibiliade do projeto e sua falta afetará os objetivos do Projeto. (Por exemplo, o produto final pode não funcionar como necessário).
• Should have (Deveria Ocorrer) : A mudança é importante e sua ausência enfraquece o Business Case. No entanto, o projeto ainda assim atingirá seus principais objetivos.
• Could have (Poderia ocorrer) : A mudança é útil, mas sua ausência não enfraquece o Business Case.
• Won’t have for now (Não ocorrerá- por enquanto) : A mudança não é essencial e não é importante; então pode esperar.

No entanto, pode ser difícil de explicar que estes quatro níveis de priorização para um solicitante e na maioria das vezes eles querem dizer que a sua Requisição de Mudança é muito importante. Então, aqui estão algumas simples perguntas que devem ajudá-lo a obter as informações corretas do solicitante:

• Must have: O produto final funcionará se não resolvido? (Sim)
• Should have: Afetam o Business Case (Sim); então pergunte como
• Could have: Isso afeta o Business Case (Não)
• Won’t have for now: Esta mudança é essencial ou importante (Sim)

Gravidade

A técnica MoSCoW é boa para priorizar, mas qual é a classificação da gravidade de uma issue?

Exemplo: Você pode usar uma escala de números como 1-5 ou palavras de significado como menor, significante, maior e crítica.

Você pode vincular um nível de gravidade a uma issue, ligando uma gravidade a um papel.

• Gravidade Menor > Suporte do Projeto
• Gravidade Normal > Gerente do Projeto
• Graviade Significante > Autoridade de Mudanças
• Gravidade Maior > Comitê Diretor do Projeto
• Graviade Crítica > Gerência do Progrma (e.x. projeto saiu da tolerância)

Autoridade de Mudança e Orçamento para Mudanças

A Autoridade de Mudanças é uma pessoa ou grupo que consideram as requisções de mudança e não conformidades. É de responsabilidade do Comitê Diretor do Projeto, assim eles podem fazer isto eles mesmos, o que é mais comum quando poucas mudanças são esperadas; ou eles podem atribuir isso a outras pessoas. Se muitas mudanças forem esperadas, então isso irá demandar muito do tempo do Comitê Diretor do Projeto e é melhor dar autoridade a outra pessoa ou grupo de pessoas.

Que tipo de pessoas pode assumir esse papel?

Isso tudo depende do tamanho e valor do projeto, o Orçamento para Mudança, a quantia que a Autoridade de Mudança pode gastar em cada mudança e outros fatores. Assim, poderia ser um “braço” do Executivo, alguém do Comitê, uma pessoa do Financeiro ou qualquer outra pessoa competente. Deve ser capaz de representar o Negócio.

A Autoridade de Mudanças terá um Orçamento para Mudanças, que é uma soma em dinheiro que o cliente e o fornecedor concordam em usar para financiar o custo das Requisições de Mudanças. É aconselhável ter um orçamento de mudança para cada projeto. O Comitê Diretor do Projeto pode limitar o custo de uma única mudança ou limitar o montante a ser gasto por estágios.

O processo de Controle de Mudança é uma ferramenta muito importante para o Gerente do Projeto. Vamos dar-lhe um exemplo. Você tem membros seniores da organização que requisitam mudanças e você não quer aparecer negativo ou ser forçado a adicionar algo novo que vai colocar o projeto em risco. Assim quando lhe pedirem para adicionar algo novo ao projeto, você pode começar dizendo “Certamente. Este é o nosso processo de Requisção de Mudança e aqui está o nosso formulário de Requisção de Mudança. Eu posso explicar isso para você ou ajudá-lo a preencher-lo”. Adicionalmente, você poderá explicar por que tal formulário é importante para o Projeto e para a Organização. Você pode então passar a requisçao de mudança para a Autoridade de Mudanças e você nunca tem que dizer não e pode aparecer assim útel em todos os momentos.

O Procedimento de Gerenciamento de Configuração

Gerenciamento de configuração é um conjunto de atividades que mantem e controlam as mudanças para cada produto durante todo o ciclo de vida do projeto, e depois que o projeto está concluído. Ou seja, olhar e acompanhar os produtos do projeto. O PRINCE2 sugere que as seguintes 5 atividades sejam seguidas:

• Planejamento : A que nível vamos fazer o GC – quão detalhado, quais produtos?
• Identificação : Ex:. Sistema de codificação (projeto-produto-dono-versão-data)
• Controle : Atividades como criar linha de base, arquivamento, distribuição de cópias, etc,
• Descriçao do Status : Check-up e relatório sobre um grupo de produtos
• Verificação e Auditoria : Estão os produtos de acordo com documentos do RIC?

Planejamento

Decidir quais documentos e produtos que você deseja controlar, então o que você acha que é importante?

Ex.: um projeto de CRM: Você pode desejar acompanhar os seguintes documentos:

Produto Principal, todos os principais componentes, documentos de design, processos, documentação do usuário

Ex.: um projeto para um evento para 100 participantes, você pode querer olhar:

Lista de convidados, notas dos palestrantes, panfletos, informações históricas restauradas, contratos locais, etc.

Identificação

Decidir como identificar cada produto exclusivos do projeto (decidir sobre um sistema de codificação).

Código do Produto - Initials do Dono - Número da Versão - Número da última modificação

Controle

Controle está relacionado a como controlar as alterações feitas aos produtos durante o projeto, como uma vez que um produto é aprovado “nada se move e nada muda sem autorização”. Linha de Base de Produtos também é usada para comparar a situação atual com os objetivos anteriores definidos.

Controle também lida com o armazenamento e a distribuição de cópias, controle de acesso, arquivamento e outras atividades de gerenciamento e produtos especialistas.

Dica: Pense em um projeto recente que você trabalhou e como você controlava o acesso a documentos e impedia que outros usuários de fazer alterações ao acordaram os documentos.

Descrição de Status

Isso é algo que talvez você nunca fez ou nunca viu em um projeto, mas é bom saber que esta atividade existe e pode ser usada se necessário. Isto está muito relacionado aos dados armazenados nos documentos RIC e o estado dos produtos; geralmente com os dados:

• Identificador, versão, última atualização, status atual, dono, lista de usuários
• Data da próxima linha de base, relacionamento com outros itens, etc…

Verificação e auditoria

Isto é para verificar se os produtos estão em conformidade com os dados do Registro de Itens de Configuração. Por exemplo: certos usuários têm acesso às versões de produto correto? Estão os produtos onde eles deveriam estar? Eles têm os números de identificação corretos? Estão os produtos assegurados?

Procedimento de Controle de issues e de Mudanças

Controle de Issue e de Mudanças está relacionado em como lidar com issues, que poderia ser a requisição de mudança, Não conformidade e Problema/Preocupações (ou outro). Existem 5 passos para Issue e Gerenciamento de Mudanças: Capturar, Examinar, Propor, Decidir e Implementar. Dica: CEPDI

• Capturar : Determine o tipo de issue, formal, informal, qual tipo? (são os 3 tipos)
• Examinar : Avaliar o impacto da issue sobre os objetivos do projeto.
• Propor : Propor ações para tomar - assim identificar as opções, avaliar e recomendar.
• Decidir : Alguém decide aprovar, rejeitar… a solução recomendada.
• Implementar : Colocar a solução recomendada em ação (tomar ações corretivas).

Lidar com Issues do Projeto

• Requisição de Mudanças - Um formulário de Requisição de Mudanças será preenchido pelo solicitante (Descrição, prioridade, custos, opções recomendadas, etc.);
• Não Conformidade - Registro de Issue deve ser preenchido;Relatório de Issue será preenchido com o detalhando da não conformidade; A Autoridade de Mudanças vai decidir sobre como lidar com esta não conformidade.
• Problema / Preocupação - (outro)Registro de Issue deve ser preenchido; Estas são outras issues que naturalmente podem ser positivas ou negativas;O Gerente do Projeto pode lidar com estas issues se estiver dentro de sua tolerância, ou pedir orientação se conduzir o estágio para fora da tolerância.

Papéis e Responsabilidades

• Gerência Corp/ Programa
  • Fornecer a estratégia corporativa ou do program para o controle de mudanças, resolução de issues e gerenciamento de configuração.
• Executivo
  • Determinar a Autoridade de Mudanças e o Orçamento de Mudanças.
  • Definir a escala para a classificação de gravidade, issues, e classificações de prioridade (1-5 ou baixo, médo, alto).
  • Responder a solicitações de orientação do GP durante o projeto.
  • Tomar decisões sobre as issues que são escaladas pelo Gerente do Projeto.
• Usuário Principal
  • Responder por solicitações de orientação do Gerente do Projeto.
• Fornecedor Principal
  • Tomar decisões sobre as Issues escaladas do Gerente do Projeto.
• Gerente do Projeto
  • Gerenciar o procedimento de Gerenciamento de Configuração.
  • Gerenciar as issues e o procedimento de Controle de Mudanças.
  • Criar e manter o Registro de Issue e implementar ações corretivas.
• Gerente de Equipe Especialista
  • Implementar ações corretivas que foram atribuídas pelo Gerente do Projeto.
• Garantia do Projeto
  • Fornecer conselhos sobre a análise e resolução de issues e verificar que os procedimentos da estratégia de gerenciamento de configuração estão sendo seguidos.
• Suporte do Projeto
  • Administrar o Gerenciamento de de Configuração (olhar após os Produtos do Projeto são concluídos).
  • Fazer as tarefas administrativas para os procedimentos de issue e controle de mudanças.
  • Manter os Registros de Itens de Configuração para os produtos.