Assistência GPS no roteiro de uma implantação de EPM
Este artigo faz parte da nossa coleção "From the Trenches". Ele descreve como fazer uma implantação do Enterprise Project Management "roadmap" quando você planeja implementar o EPM. Ele descreve exclusivamente os fatores a serem considerados quando você planeja seu caminho de implantação.
Para ver mais artigos, consulte white papers "From the Trenches".
Assistência do G.P.S. no roadmapping de uma implantação do EPM
Na minha última coluna, falei sobre como usar uma abordagem em fases para criar seus planos para uma implantação da Solução EPM (Enterprise Project Management) da Microsoft. Hoje, abordaremos a criação de um roteiro de implantação do EPM como parte do seu plano de projeto.
Se você esteve no Microsoft Live Maps, sabe que as direções exigem duas coisas: um destino e um ponto de origem. Quando aplicamos essa analogia a uma implantação do EPM, temos que pensar em termos semelhantes:
Ponto de origem definido em termos de tecnologia, processo e pessoal
Destino definido em termos de negócios e priorizado
Também podemos querer definir algumas "estações de maneira" ou paradas provisórias onde você pode se reagrupar, tirar fotos, desfrutar do cenário por um tempo e repor seus suprimentos para a próxima etapa da viagem.
Ao fazer um roteiro ou direções, é muito comum ter duas escalas. Mantemos a próxima etapa da viagem em grande detalhe, até uma rota turn-by-turn. Podemos também, no entanto, manter um mapa de nível mais alto de toda a viagem com menos detalhes para manter nossa perna atual no contexto de toda a viagem. Em termos de gerenciamento de projeto, chamamos isso de "planejamento de ondas rolando".
"Direções"
Ao fazer um roteiro de implantação do EPM, sempre começamos com a visão ou a intenção de onde a empresa está indo em termos de seus esforços de EPM. Isso nos dá o destino que precisaremos para fazer direções como o Microsoft Live Maps faria.
Se estivéssemos apenas para perguntar: "O que você quer?" a resposta quase invariavelmente vem em termos de uma solução. Pessoas provavelmente dirão "Preciso de um relatório parecido com este" ou "Nossa empresa precisa de análise de portfólio".
Para aqueles de nós no negócio de soluções, sabemos que esses tipos de notas de design estão cheios de riscos. Treinamos nossos consultores para ouvir clientes que descrevem seu problema como uma solução. "Essa é uma solução para um problema", vamos dizer, "não o problema. Vamos definir o problema".
Então nós tendemos a não perguntar "O que você quer?" Em vez disso, perguntas que podem ser úteis durante uma previsão podem incluir:
"Qual decisão de negócios você agora não pode tomar ou é capaz de tomar apenas com grande dificuldade, cujo preparo seria facilitado como resultado dessa implantação do EPM?"
Ou:
"Qual aspecto da organização você acredita que poderia ser mais eficiente por meio de um aumento na taxa de transferência ou uma diminuição no esforço por meio dessa Implantação do EPM?"
Agora, de quem deveríamos fazer essas perguntas? Ora, as pessoas que tomam essas decisões, é claro! Se você já teve uma minivan cheia de crianças e se virou para perguntar-lhes onde você deve ir como um destino, você sabe que você terá 50 respostas.
Pelo mesmo token, precisamos ter certeza de que os tomadores de decisão da organização são uma parte fundamental desse processo ou corremos o risco de escolher uma direção para a qual o "driver" não está preparado para viajar. Há um benefício adicional para trazer a alta administração para o processo de roadmapping do EPM neste momento. Além de ser um participante crítico na escolha da direção em que a implantação do EPM deve ir, eles também são capazes de ter uma noção da magnitude do projeto. Um dos desafios mais comuns e difíceis para uma implantação bem-sucedida do EPM é o suporte ao gerenciamento de longo prazo. Alguns executivos seniores não consideraram o quanto isso pode mudar as práticas e procedimentos existentes e o quão disruptivo, mesmo temporariamente, isso pode ser. Eles também podem não ter uma apreciação de quanto esforço um projeto de mudança de cultura como o EPM pode ser.
Durante nosso trabalho com o gerenciamento sênior, bem como o gerenciamento de projetos e talvez o pessoal de linha, tentamos conectar decisões de negócios ou eficiência comercial com processo e tecnologia. Há um processo que deve ser criado para atender a esse requisito? O que ele precisaria realizar? Existe uma função do sistema que existe ou deve ser criada para atender a essa decisão de negócios? O que ele precisaria entregar?
A análise básica de sistemas é fundamental nessa fase. Começamos com a decisão comercial "saída" e trabalhamos nosso caminho de volta para os elementos de dados necessários para tomar essas decisões. Em alguns casos, descobrimos que os dados básicos simplesmente não estão lá e isso resulta nesse elemento do roteiro sendo sinalizado como "alto risco". Afinal, agora precisamos incluir a coleta de dados em um novo formato ou estrutura para capturar esses novos elementos de dados antes mesmo de podermos pensar em entregar o melhor processo de negócios, e isso pode ser uma ordem alta em alguns casos.
Temos mais uma coisa a fazer antes de fechar o processo de destino e isso é priorizar os diferentes elementos da visão final. É muito comum pensar no início do processo de roadmapping que as prioridades irão para um lado, mas descobrir que, à medida que você vai para realmente registrá-los, eles vão muito diferente. Curiosamente, quando todos concordaram sobre quais destinos estão incluídos em nosso destino, há um consenso notável sobre quais devem ser as principais prioridades.
A próxima coisa que precisamos para direções é um ponto de origem e gerenciamos isso por meio de um inventário de onde a organização está agora em relação às metas que escolhemos.
Nós olhamos para o pessoal existente. Eles são treinados no gerenciamento de projetos para suas funções específicas? Temos pessoal suficiente com experiência suficiente para alcançar as metas que foram definidas? Lembre-se de que temos que examinar várias medidas aqui porque pessoas diferentes terão uma função diferente no eventual processo de gerenciamento de projetos corporativos. Não faz sentido treinar cada funcionário para ser um agendador de projeto se, de fato, eles nunca serão responsáveis por criar agendas. Por padrão, pensamos em quatro funções: Administrador, Gerenciador de Projetos, Recurso Individual e Executivo. Se os quadros de tempo estiverem envolvidos, também consideraremos supervisores como a quinta função. Claro, dependendo do destino que definimos em nosso processo de previsão original, as funções podem ser bem diferentes. Isso altera profundamente o processo de inventário de habilidades, e é por isso que sempre começamos definindo o destino antes de pensar no ponto de origem.
Também analisamos o processo existente. Há um processo de gerenciamento de projeto declarado ou documentado? Como é mantido? Quem está no comando disso? Se houver um Office de Gerenciamento de Projetos já estabelecido, muito desse esforço será focado lá. Afinal, não adianta criar novos procedimentos se houver procedimentos e processos existentes que já estejam em vigor. Podemos inventar processos existentes que estão dentro do processo atual de gerenciamento de projetos e fora, dependendo de quais serão as metas finais do ambiente EPM.
Por exemplo, podemos ter decidido que o gerenciamento de contratos será um elemento significativo do nosso novo ambiente EPM e que isso nunca fez parte dos processos de gerenciamento de projetos nessa organização. No entanto, se olharmos um pouco mais longe, podemos descobrir que a organização tem um forte conjunto de controles para gerenciar documentos e o fluxo de trabalho existente já movendo documentos, talvez no SharePoint. Esse seria um processo ideal para adotarmos e, se necessário, ajustarmos para garantir que ele capacite esse aspecto do novo ambiente de gerenciamento de projetos corporativos. Isso traz um benefício de três bordas. Primeiro, não precisamos gastar o esforço criando um novo processo. Em segundo lugar, sabemos que o pessoal já tem as habilidades e hábitos para usar o processo dessa forma, o que significa nenhum esforço de treinamento ou esforço para fazer com que o pessoal cumpra. Por fim, não temos a situação difícil de tentar criar um processo separado que possa estar em desacordo com um processo existente para gerenciar documentos, como contratos.
Sabemos que um dos nossos maiores desafios será a conformidade. Não criar o sistema, mas fazer com que todos o usem e usá-lo consistentemente. Quanto mais podemos adotar hábitos, práticas e procedimentos existentes inseridos na organização, mais fácil será a conformidade.
Por fim, você precisa de um inventário da plataforma de tecnologia. Como a Solução microsoft EPM é criada em uma plataforma de tecnologia, é provável que encontre parte dessa tecnologia já em vigor, mas também é possível que a organização tenha que atualizar parte de sua plataforma para que a solução que você está projetando funcione. SharePoint e SQL Server são elementos óbvios de implantação do Microsoft Office Project Server, mas você também pode precisar verificar a compatibilidade do navegador (todos estão usando a versão mais recente do Internet Explorer?), status de segurança (o sistema estará voltado para fora?), qual versão do SQL Server é implantada (é o OLAP Services ou o OLAP Services ou SQL Server Reporting Services já está sendo usado?). Você também pode precisar considerar outros sistemas com os quais precisará fazer interface ou integração. Como você terá acesso a esses sistemas em produção?
O tamanho do sistema planejado também pode precisar examinar hardware, rede e outros elementos de infraestrutura para garantir que o sistema tenha a estrutura necessária quando ele chegar.
Assim como acontece com qualquer sistema empresarial, você deseja planejar uma área de produção e preparo para que atualizações e aprimoramentos possam ser criados no laboratório e não no sistema ao vivo ao longo do tempo. Você também pode ter que fazer planos para uma fase Piloto ou Prova de Conceito; algo sobre o qual falarei mais na minha próxima coluna.
"Rota de recalculação"
Quando a unidade G.P.S. no meu carro descobre que perdi uma curva, a voz de uma senhora muito agradável diz "Rota de recalculação". Momentos depois, a linha através do meu mapa muda e eu tenho novas direções. Em uma implantação do EPM, precisamos estar prontos para um desvio ou uma curva bloqueada para reparos. Talvez tenhamos perdido a saída da auto-estrada. Como lidamos com a replanificação? Há duas coisas para perguntar quando você sai do curso: primeiro, você ainda está indo para o mesmo lugar? Segundo, como vamos chegar daqui? Uma das minhas citações favoritas de gerenciamento de projetos sobre este assunto vem de Napoleão Bonaparte, que uma vez disse: "Um plano de batalha dura até o contato com o inimigo."
Em uma implantação do EPM, como aplicar esse mesmo princípio? Em primeiro lugar, você precisa de uma medida para determinar se você não está mais no curso. Se um membro da equipe tem uma consulta de dentista de emergência amanhã e está ausente do escritório por quatro horas, devemos então deixar essa discrepância mudar todas as tarefas downstream, reagendar todos de amanhã ao meio-dia até o final do projeto, e então enviar e-mail a todos com seus novos tempos de atribuição?
Claro que não.
Uma discrepância de quatro horas para um recurso durante o tempo de vida de seis meses de um projeto envolvendo dezenas de pessoas não é suficiente para justificar a alteração do nosso caminho. O que precisamos fazer para iniciar qualquer tipo de projeto empresarial é definir limites de progresso aceitável. O mundo aeroespacial e de defesa está encontrando um novo termo para este ultimamente, "Tripwires", que é muito descritivo. Podemos estabelecer quais critérios nos indicariam que nossa rota precisa ser recalculada. Há várias métricas ou medidas típicas a serem consideradas. Primeiro, se o custo de conclusão projetado varia mais de X% do orçamento original, isso pode constituir uma revisão do plano de projeto. Você pode fazer a medida de custo em horas de trabalho ou dinheiro. Qualquer um é eficaz. Talvez se a data de término prevista variar mais de X dias a partir da data de término originalmente planejada, isso pode constituir uma revisão do plano de projeto.
Você também pode decidir que perder determinados marcos importantes em mais de um determinado número de dias é um fio de viagem, ou você pode identificar certos riscos sendo realizados como um fio de viagem, ou você pode determinar que uma mudança de certos membros principais da equipe de projeto, como o patrocinador executivo, é um fio de viagem. É mais importante definir alguns critérios do que acertar exatamente os critérios. Além disso, lembre-se de que você precisará medir esses critérios ao longo do tempo de vida do projeto, portanto, se você escolher 50 ou 100 métricas diferentes, poderá acabar gastando mais tempo medindo o projeto do que fazendo o projeto!
Depois de determinar que está fora do curso, a melhor maneira de voltar aos trilhos é realizar uma revisão do plano de projeto. Recomendamos incluir a representação do grupo original de gerenciamento sênior que ajudou a estabelecer nosso destino em primeiro lugar e do grupo dentro da equipe de gerenciamento de projetos que ajudou a fazer o inventário original. As revisões do Plano de Projeto podem ficar atoladas ao atribuir a culpa pelo motivo pelo qual o projeto está fora dos trilhos e por que um determinado tripwire foi disparado. Esse esforço pode ser extremamente contraproducente. Recomendamos focar nas seguintes perguntas:
O que está acontecendo?
Onde acabamos? Qual é o nosso ponto de origem atual?
Ainda estamos comprometidos com nosso destino original ou há uma razão convincente para revisar esse processo ou mesmo refazer o processo de previsão?
Precisamos redefinir algum de nossos marcos ou fases intermediárias?
Precisamos mudar alguma equipe de projeto?
Precisamos redefinir alguma de nossas métricas de tripwire?
As perguntas que achamos menos produtivas incluem:
De quem é a culpa que estamos aqui? Quem é o responsável? Quem é o culpado?
Como vamos "voltar" aos trilhos; de volta ao plano antigo?
O motivo mais comum para uma revisão de plano de projeto é que as prioridades da organização mudam. Por exemplo, itens que foram projetados para estar na Fase 3 estão sendo exigidos na Fase 2. Isso geralmente é um sinal de uma dinâmica saudável dentro da organização e o resultado de pessoas começando a pensar seriamente sobre as implicações da implantação do Sistema EPM.
Mau tempo
Antes de sair em uma longa viagem, você provavelmente verificará o Canal do Tempo (ou weather.msn.com) para garantir que nenhum tempo inclemente afetará sua viagem. Os riscos fazem parte da vida. Lembre-se de que, se não houvesse riscos, não haveria necessidade de gerentes de projeto! Planejar os riscos mais gritantes não é um processo complicado. Comece no início do processo de previsão e, ao examinar cada um dos elementos do destino que está projetando, pergunte ao grupo quais barreiras alcançar esse destino eles podem pensar. Em alguns casos, os riscos serão significativos. Não é incomum que uma organização deseje um resultado específico, apenas para descobrir que os dados brutos necessários para entregar esse resultado nunca foram coletados e que pode haver uma resistência considerável à coleta desses dados.
Em um exemplo, encontramos uma organização que queria planejamento de capacidade de recursos. Isso exigiria uma contabilidade completa de toda a disponibilidade de recursos de todo o pessoal do projeto e uma contabilidade completa de todas as cargas de trabalho possíveis que poderiam ser aplicadas a esses funcionários. Quando perguntamos se ambos estavam disponíveis, fomos informados de que, com certeza, eles estavam disponíveis, mas apenas para dois quintos da organização. Quando descobrimos então que os três quintos da organização para os quais os dados não estavam disponíveis nem estavam representados na reunião de previsão, dissemos: "Vamos adivinhar. Os problemas que você está enfrentando com o planejamento de capacidade de recursos estão nessas três divisões.". Naturalmente, eles eram, e tivemos que identificar o registro dos líderes de divisão dessas divisões como uma fase separada do projeto e um risco muito alto.
À medida que você passa a trabalhar com o gerenciamento de projetos e o pessoal de linha no processo de inventário, peça durante as entrevistas quaisquer riscos que esses funcionários possam identificar.
Depois que os riscos forem identificados, é importante organizá-los. Se você não tiver feito isso antes, as informações mais básicas serão as mais valiosas. Inclua:
Uma breve descrição do risco
A área ou a fase do projeto que ele pode afetar
A gravidade do risco se os critérios forem realizados
Por fim, uma das coisas mais importantes que você pode fazer é adicionar alguns detalhes sobre mitigação de risco. Apenas pensar em um risco é um fator atenuante enorme, mas enquanto a implantação do EPM está em sua infância, inserir algumas anotações sobre como você pode lidar com um risco específico durante o projeto pode ser inestimável. É comum que as decisões sejam tomadas às pressas em um contexto emocional quando os riscos são realizados. Ter algumas anotações que foram pensadas enquanto as cabeças mais frias prevaleceram pode ser útil.
Vamos dirigir o carro que estamos construindo
Aqui está uma dica sobre como fazer seu roteiro que pode pagar enormes dividendos: use o Project Server e a Solução Microsoft EPM para ajudar a criar e gerenciar seu plano de roteiro. Parece óbvio talvez, mas é raro o suficiente para as organizações fazerem isso nós mencionamos isso aqui.
Uma vez um gerente sênior me disse que sua equipe de projeto havia perguntado se ele achava que usar a solução microsoft EPM para implantar a Solução Microsoft EPM não era um exagero. "Se construíssemos aviões a jato para viver, não os voaríamos para trabalhar", disseram eles. "Você está brincando?", Respondeu ele. "Se eu pudesse pilotar um avião a jato para trabalhar, eu faria isso todos os dias!"
Na verdade, usar a solução Microsoft EPM para a equipe de implantação do EPM é uma ótima ideia.
Instalar o Project Server e os outros elementos da Solução Microsoft EPM não é um grande desafio técnico e, com o mínimo absoluto de configuração, você pode estar em execução com uma pequena equipe de implantação como os usuários dentro de alguns dias. Essa é uma ótima maneira para os usuários que se tornarão seus campeões de implantação se familiarizarem com o uso e os benefícios do sistema antes que ele chegue às mesas da maior parte da equipe.
Essa implantação não deve ser seu ambiente de produção. Você certamente estará configurando isso e personalizando-o para cumprir a visão do destino original. Você quase certamente não estará trabalhando em coisas como agendamento de vários projetos ou planejamento de capacidade de recursos ou otimização de portfólio em sua iteração de implantação do EPM do Project Server, mas você será capaz de entregar um sistema que pode fornecer grandes benefícios. Recomendamos:
Faça uma agenda de ondas rolando como um projeto publicado.
Um cronograma de ondas rolando destaca a fase atual em grandes detalhes e fases futuras como mais um resumo. Isso permite que os membros da equipe saibam no que precisam trabalhar agora e ainda permite que eles vejam o projeto em um contexto maior.
Gerencie o documento de visão no Workspace do Project.
O Project Workspace é um site do SharePoint vinculado ao projeto que, por padrão, inclui uma área para Problemas, Riscos e Documentos. Por que não colocar todos os documentos do projeto aqui para o projeto de implantação do EPM e instituir o controle de versão do SharePoint para que você sempre possa voltar à versão original?
Coloque suas aprovações de marco e "portões" nas entregas do Project Workspace.
Esta é uma lista de tarefas simples que você pode vincular a tarefas no Project Server. Ele dará uma visão muito high-end do projeto e é uma ferramenta fácil de usar para o gerenciamento de limites para determinar quando você vai "fora do curso".
Coloque o gerenciamento de alterações no Workspace do Project como problemas.
O gerenciamento de alterações é um dos grandes desafios dos projetos de tecnologia. À medida que novas sugestões de alterações no projeto surgem, obtenha-as na área Problema como uma possível alteração a ser gerenciada. Ao adicionar alguns campos a essa área, você pode obter uma lista de itens de alta prioridade e quem é responsável por eles a qualquer momento.
Coloque os riscos do projeto no Workspace do Projeto.
Além de documentos e problemas, a área de risco do Workspace é o local ideal para adicionar seus riscos e planos de mitigação. Na verdade, a tela padrão tem todos os campos lá prontos para você usar.
Falta muito?
"Quase. Estaremos lá em breve.
Uma implantação do EPM pode levar uma organização a tantos lugares diferentes que não há como simplesmente publicar a agenda padrão para todos. Mas alguns minutos pesquisando na Internet podem fornecer muitos exemplos possíveis para diferentes partes do projeto. Se eu resumir o exercício de roteiro acima, é provável que você acabe com um projeto que tenha algumas fases óbvias:
Exercício de roteiro
Visualização (Escolha o destino)
Inventário de processos existentes (Identifique o ponto de origem)
Inventário de pessoal existente (Identifique o ponto de origem)
Inventário de tecnologia (Identifique o ponto de origem)
Implantação da solução EPM para a equipe do EPM
Fase 1
Design
Configuração, Personalização, Documentação
Piloto
Treinamento
Distribuição
Examinar a Fase 1 e ajustar a Fase 2 conforme necessário
Fase 2
Fase 3
Fase 4
Encerramento do projeto
Aplicar um exercício de roteiro à implantação do EPM pode alterar a experiência de caótica para gerenciável muito rapidamente. Lembre-se de escolher seu destino primeiro, descobrir seu ponto de origem em seguida e desenhar o caminho entre eles.
Viagem feliz!
Sobre o autor
Chris Vandersluis é presidente e fundador da Montreal, hms software com sede no Canadá, um parceiro certificado pela Microsoft. Ele é formado em economia pela Universidade McGill e tem mais de 30 anos de experiência na automação de sistemas de controle de projetos. Ele é membro de longa data do PMI (Project Management Institute) e ajudou a fundar os capítulos montreal, Toronto e Quebec do Grupo de Usuários do Projeto Microsoft (MPUG). As publicações para as quais Chris escreveu incluem Fortune, Heavy Construction News, Computing Canada magazine, e PMNetwork do PMI, e ele é um colunista regular do Project Times. Ele ensina Gerenciamento Avançado de Projetos na Universidade McGill e frequentemente fala em funções de associação de gerenciamento de projetos em América do Norte e em todo o mundo. O HMS Software é o editor do sistema de timekeeping orientado ao projeto TimeControl e é um Parceiro de Solução de Projeto da Microsoft desde 1995.
Chris Vandersluis pode ser contatado por email em: chris.vandersluis@hms.ca
Se você quiser ler mais artigos relacionados ao EPM por Chris Vandersluis, consulte o site de Diretrizes do EPM do HMS (https://www.epmguidance.com/?page_id=39).