O Bat-fone

O título deste artigo refere-se ao uso liberal do Batfone pelo Comissário Gordon sempre que a Cidade de Gotham estava em apuros (da série de TV "Batman" dos anos 1970).

Este artigo faz parte da nossa coleção "From the Trenches". Ele relaciona a história fictícia de "Batman" a como, durante uma implementação do EPM, em algum momento poderíamos desejar ter acesso a um Batfone quando estamos em apuros. Ele também discute muitas maneiras de evitar problemas durante a implementação.

Para baixar a versão do Word deste artigo, consulte O Batphone.

Para ver mais artigos, consulte white papers "From the Trenches".

O Batfone

Em 1966, a série de TV original do Batman entrou no ar. Durou apenas 120 episódios, mas mudou uma cultura de maneiras que duram até hoje. No mundo de Batman e Robin (interpretados por Adam West e Burt Ward), havia uma solução de "morcego" para tudo. Não importa qual seja o problema, Batman teria a solução. O Batmóvel, Batboat, Batplane e Batcave tinham seu lugar. E se você era alguém que precisava de ajuda, não importa o quão difícil, como você poderia chegar ao Batman? Bem, com o Batfone, é claro! Pegue o Batfone e a ajuda estaria a caminho.

O Comissário Gordon recorreria ao Batfone quando coisas sem esperança, que ocorreram, é claro, a cada episódio. Não importava o quão difícil o desafio, pegar o Batfone e em 22 minutos (mais tempo para comerciais) o vilão seria derrotado e Gotham City voltou ao status pacífico.

Todas as soluções no mundo do Batman foram feitas para parecer um Morcego. Algemas? Forma de morcego. Correia de utilitário? Logotipos bat. Gancho? Claro , parece asas de morcego. Para minha surpresa, olhando para trás para as imagens do Batphone parecia perturbadoramente normal. Um telefone vermelho com um mostrador (lembra-se deles?) Não sei por que tinha uma discagem. Ele só chamou um lugar: a Batcave, onde a salvação estava à mão.

Por mais nostálgico que possa ser pensar em telefones com discagens e os episódios antigos de Batman, não é realmente o ponto do artigo de hoje. Já se passaram 40 anos desde que o Batphone foi aposentado, mas as pessoas fazem chamadas para consultores do EPM todos os dias esperando que o Batphone funcione para apenas mais uma chamada.

Seus vilões são variados. Alguns são técnicos; eles precisam atualizar da versão x para a versão y. Alguns são arquitetônicos; eles precisam fazer o sistema EPM interno falar com usuários no mundo exterior. Alguns são culturais; os usuários se recusam a usar o sistema. E alguns são processuais; o processo que eles estão seguindo não parece entregar o resultado esperado.

Não importa qual seja o desafio, a solicitação para a consultoria é a mesma: você pode corrigi-lo em 22 minutos?

É uma situação em que um número surpreendente de usuários do EPM entra em uma situação em que eles precisam urgentemente de ajuda para tirá-los de uma situação difícil. Muitas vezes é uma emergência e a solução é exigida pelo gerenciamento ontem. As pessoas que fazem essas chamadas (recebo um casal a cada semana) não têm a mente fraco. Eles são gerentes altamente inteligentes, capazes e realizados.

Não há batfone, é claro. Queria que houvesse. Eu o usaria para todos os tipos de desafios pessoais. E assim as pessoas que fazem essas chamadas raramente estão satisfeitas com as respostas que recebem. Então, vamos dar alguns momentos e falar sobre como as pessoas acabam em um lugar tão apertado que eles sentem que precisam pegar o telefone vermelho e como você pode evitar ser um deles.

Entrando em problemas

Primeiro, vamos falar sobre como as pessoas entram em problemas ao fazer uma implementação do EPM. Há algumas causas comuns:

• Subestimar o desafio Esse é, de longe, o erro mais comum em uma implantação do EPM. Não quer dizer que cada implantação deve ser grande e difícil. Isso certamente nem sempre é o caso. Mas, talvez por causa do pensamento desejado, é incrivelmente comum subestimar o que será necessário para obter os benefícios de uma implantação do EPM. O primeiro erro em subestimar é escolher o destino. Algumas pessoas escolhem a instalação da ferramenta como um projeto bem-sucedido. Não é, é claro. Algumas pessoas escolhem o primeiro uso da ferramenta ou o primeiro relatório que sai da ferramenta como o destino. Também não é isso. Uma resolução de quaisquer problemas para os quais as ferramentas do EPM foram escolhidas é para onde você precisa direcionar. Isso significa que a cultura mudou, o treinamento está concluído, o uso está em produção, as ferramentas estão funcionando, os dados estão lá. Sim, isso pode ser uma grande coisa , mas se você está a uma polegada do objetivo, você ainda não tem nada. (Bem, quase nada, de qualquer maneira.)

• Tornando-o um projeto técnico Para aqueles de nós no negócio de tecnologia, somos os mais culpados disso e, na verdade, a maioria de nós sabe melhor. No entanto, de alguma forma, a tentação de acreditar que a disponibilidade da tecnologia significa que o problema é resolvido é difícil de resistir. Tantas organizações que visitamos dizem alguma variação de "mas instalamos o Project Server, por que nosso pessoal está sobrecarregado? Como já dissemos há algum tempo, fazer o gerenciamento de projetos empresariais funcionar é uma combinação de pessoas, tecnologia e processo e uma boa quantidade de gerenciamento de mudanças geradas para uma boa medida. Isso não chega automaticamente quando o DVD de software passa pela porta.

• Não envolvendo o gerenciamento Isso também acontece com muita frequência. Afinal, as pessoas que melhor entendem os benefícios de um sistema de gerenciamento de projetos corporativos são provavelmente aquelas que estão lutando para analisar as vastas quantidades de dados provenientes de um ambiente com muitos projetos e muitos recursos. O gerenciamento de projetos corporativos é mais popular quando uma organização tenta reconciliar um conjunto complexo de prioridades conflitantes e uma combinação miríade de habilidades e experiência. Você pensaria que a gestão estaria naturalmente envolvida em tal projeto, mas muitas vezes não é o caso. O desafio de mudar a cultura corporativa de uma única mentalidade de projeto para uma mentalidade de projeto empresarial é quase impossível de superar sem eles e, no entanto, muitas vezes o gerenciamento é ignorado devido a uma preocupação de que eles não serão capazes de apreciar o que será necessário para concluir uma implantação do EPM.

• Fazendo agendamentos irreais Não há ninguém que deseje que uma implantação do EPM leve muito tempo. E é comum esperar que o projeto possa ser realizado em dias ou algumas semanas, em vez dos meses mais comuns. Há também um desafio comum de não obter os recursos para um projeto "interno", como o EPM, tão prontamente quanto um projeto comercial ou baseado no cliente. Por essas e outras razões, é comum fazer um agendamento de projeto com requisitos de recursos que são lamentavelmente insuficientes.

• Não aplicar o gerenciamento de projetos ao sistema de gerenciamento de projetos Se você leu algo que eu escrevi, as chances são de que você já viu isso antes. Os gerentes de projeto são suscetíveis à síndrome "sapateiro cujos filhos estão descalços". O resultado é uma falta comum de uma carta de projeto, um orçamento aprovado, um cronograma rastreado, recursos dedicados e todos os outros accoutrements para seu próprio projeto que são comuns a todos os outros projetos que gerenciam.

O que eles esperavam?

Ok, é assim que as pessoas muitas vezes se encontram em apuros. Os benefícios esperados pelo gerenciamento da implantação de um sistema EPM geralmente vêm diretamente de desafios empresariais. É a promessa de resolver esses desafios que trazem gerenciamento para aprovar os gastos com software, hardware, infraestrutura e possivelmente até serviços. O mais comum desses desafios pode soar familiar:

• Os recursos estão sobrecarregados Pode não estar claro em que os recursos estão sendo gastos, mas é muito comum descobrir que os recursos estão sobrecarregados. Um problema mais complexo é descobrir que alguns recursos estão sobrecarregados e outros estão sub-carregados, o que geralmente indica uma incompatibilidade entre as habilidades e a experiência disponíveis em relação às necessárias.

• Projetos críticos não estão sendo concluídos em tempo hábil Deve ser óbvio que projetos críticos devem ser concluídos quando são planejados, mas a vida parece interromper tais planos. Isso pode ser devido a requisitos de recursos conflitantes, escolher muitos projetos que exigem muitos da mesma habilidade ou apenas priorização ruim. Às vezes, as organizações pensam que é uma falta de habilidade do gerente de projeto, mas em um ambiente de matriz multiprojeto e multi-departamento, mais provável é que o culpado seja de natureza organizacional.

• Projetos não estão sendo concluídos dentro do orçamento O que se mantém verdadeiro para o agendamento pode se aplicar igualmente aos custos. Em alta tecnologia, bem como em muitos outros setores, o componente mais variável do custo de um projeto é a quantidade de mão-de-obra aplicada a ele. Demora muito mais com as mesmas pessoas e você está adicionando custos ao projeto. Um número impressionante de projetos de colarinho branco ainda não foi rastreado. Eles estão planejados, mas o custo real por projeto não é registrado.

• Sua competição está concluindo projetos mais rápido do que você Em uma economia competitiva, ser o primeiro a comercializar pode fazer a diferença entre sobrevivência e esquecimento. Portanto, para muitas organizações, verifique se o gerenciamento de projetos é pelo menos tão eficaz quanto seus concorrentes são importantes.

• Não há visibilidade sobre o que os recursos de um projeto estão gastando seu tempo ou não para saber quanto tempo está sendo gasto em cada projeto Às vezes, nenhuma resposta é pior do que uma resposta ruim. Se você está na alta administração, isso é particularmente verdade. Se você souber que os resultados são ruins, você pode aplicar suas habilidades e os recursos à sua disposição ao problema em questão. Se você sabe que algo está errado, mas não pode dizer o quê, você está algemado. Não há como saber onde tentar consertar algo.

Como fazer ficar sem problemas?

Você não quer chegar a um ponto em que sinta que precisa do Batphone. Então, o que você pode fazer com seu ambiente EPM para garantir que você não acabe lá?

Tudo o que dissemos na primeira seção é óbvio:

• Fazer uma boa estimativa

• Não pense que o EPM é apenas um projeto técnico

• Envolver o gerenciamento sênior desde o início

• Faça uma agenda realista e dê-lhe uma verificação de realidade comparando-a com outras pessoas em sua indústria

• Faça um agendamento de projeto e fretamento do projeto e faça todas as coisas que você normalmente faz com seus outros projetos

O que mais você pode fazer?

Em primeiro lugar, inicie o projeto com uma apreciação de que, em algum momento no futuro, você vai querer usar o Batphone. Você está. Sabendo disso, uma coisa que você pode fazer é orçar para assistência para a qual não tem nenhum plano atual. Recomendamos que nossos clientes orçam de 10% a 20% do projeto para "requisitos não alocados". "Para que é isso?", Sempre nos perguntam. "Você vai nos dizer mais tarde", nós sempre respondemos. É comum não usar todo esse dinheiro. Mas também é incrivelmente comum usar um pouco dele. Ter um especialista qualificado já alocado e orçamento para seu projeto faz uma enorme diferença mais tarde.

Comece com a expectativa de que o plano e as pessoas mudem. Minha citação de gerenciamento de projeto favorita é de Napoleão Bonaparte, que disse: "Um plano de batalha dura até o contato com o inimigo." É verdade para os planos do EPM, também. Dado que uma implementação provavelmente durará vários meses, a chance de que alguns funcionários mudem no plano é enorme. Então, planeje a redundância.

Os sistemas EPM evoluem. É comum nos dias de hoje em um aplicativo empresarial pensar no "custo total da propriedade". Acho que devemos incluir o ciclo de vida total do aplicativo em nossos planos de projeto do EPM. Já pensou em qual versão de uma ferramenta você está prestes a implementar? Pensou em quais outras ferramentas depende? Que tal a atualização/atualização regular dessas ferramentas? Você fez personalizações? Que tal treinamento personalizado? Você pensou em como essas coisas migrarão para uma nova versão, você deve implantar uma?

Planeje a redundância de seus especialistas também. Se você tiver um único consultor trabalhando para você, o que acontecerá em alguns meses à medida que você passar para uma nova fase de sua implementação ou introduzir um novo membro-chave da sua equipe? Esse consultor estará disponível? (Consultores passam de um projeto para o próximo para que a resposta seja muitas vezes , "não".) Se você trabalha com uma empresa de consultoria, você falou sobre como eles podem preservar o trabalho de sua equipe para que outros o replicem, se necessário?

Coloque isso por escrito

Um dos desafios mais comuns e fáceis de corrigir vem da documentação ruim. É o elemento mais fácil de alterar, mas a existência dessa documentação pode fazer a diferença entre voltar para uma referência escrita e procurar o Batphone. Também não é suficiente escrever um documento e enfiá-lo em uma gaveta em algum lugar. Os documentos devem se tornar parte de um registro contínuo e seu processo de EPM pode referenciá-los como parte de um processo de revisão regular. Aqui estão alguns dos documentos para um ambiente EPM que eu acho que são mais críticos:

• Business Case Eu não sei o que é sobre o caso de negócios original que o torna tão pouco atraente, mas é a coisa mais comum a perder o controle de e em muitos aspectos, é o kernel de por que você tem um ambiente EPM em primeiro lugar. O caso de negócios observa quais são os benefícios organizacionais esperados; o que a organização espera do sistema EPM? Quando recebemos uma chamada do Batphone, uma das primeiras coisas que perguntamos é: "Qual é o sistema esperado para entregar para você?" Não pedimos apenas ao administrador. Também pedimos gerenciamento, usuários e beneficiários de negócios. A resposta mais comum é uma resposta diferente de cada parte. Isso porque a premissa de negócios original se perdeu.

• Funções e responsabilidades Na última versão de funções e responsabilidades, muitas vezes resolvemos para o nome de um indivíduo, e não demora muito para que o papel que o indivíduo desempenha no sistema EPM seja esquecido. Manter um documento de funções e responsabilidades permitirá ajustar os parâmetros de quem faz o que no processo do EPM, à medida que a organização passa naturalmente por alterações de pessoal ou até mesmo mudanças na estrutura organizacional.

• Guia de Processo e Fluxograma Isso geralmente é esquecido quando chegamos a guias processuais. Pessoas ficam com as etapas "O que fazer" em um manual processual, mas não o contexto de por que essas etapas são importantes e o que fazemos com o resultado de cada etapa. Um guia de processo e, o melhor de tudo, um fluxograma visual permitirá que os futuros gerentes entendam o que o sistema fornece e facilitem muito a adaptação do sistema no futuro.

• Critérios de Seleção do Sistema Ao escolher seu sistema EPM e quaisquer ferramentas de terceiros que você possa ter selecionado ao longo do caminho, deixe as gerações futuras saberem em que sua decisão foi baseada. Entramos em organizações 5, 7 ou até 10 anos depois que um sistema foi implantado e vimos um sistema com várias ferramentas associadas a ele e perguntamos "Por que você está fazendo isso? Seria muito mais fácil fazer isso! As razões para essas decisões não estão em lugar nenhum. Em alguns casos, o cliente passou anos fazendo algo de uma forma extremamente complicada que poderia ter sido muito mais fácil dadas as versões mais atuais das ferramentas existentes. Eles não podem tomar uma decisão fácil de mudar uma ferramenta ou usar uma versão mais atual porque não têm mais acesso ao motivo pelo qual escolheram fazer algo de uma certa maneira anos atrás.

Não há batfone.

Quando digo isso, parece que estou dizendo que não há nenhum Coelhinho da Páscoa ou nenhum Papai Noel. É uma má notícia. Mas realmente não há batfone. Tenho certeza, porém, que apenas a ausência desse telefone mágico não vai impedir as pessoas de me ligar amanhã me pedindo para derrotar o último vilão de Gotham City. Se você se mete em problemas e sente a necessidade de chamar um especialista, aqui estão algumas recomendações:

1. Ouça os conselhos que você recebe. É bobagem pagar um especialista para lhe dar conselhos e então decidir que você sabe melhor do que eles. Se você vai pedir conselhos e está lidando com um especialista, tente ouvir e pelo menos considerar o conselho. Batman não teria continuado aparecendo para o Comissário Gordon uma e outra vez se cada vez que ele fez isso, Gordon disse: "Agora que você está aqui, Batman, por favor, faça a mesma coisa que todos os meus outros policiais fazem."

2. Batman poderia fazer isso em 22 minutos, mas você provavelmente não vai. Se você está chamando um especialista, deixe-o dizer quanto tempo deve levar para corrigir seu desafio. Você pode optar por não corrigi-lo depois que ele terminar, mas corrigir desafios do EPM, mesmo os técnicos, raramente leva apenas alguns minutos. Afinal, Batman teve que fazê-lo em 22 minutos porque 8 minutos foram alocados para comerciais, e eles são essenciais.

3. O Comissário Gordon nunca disse a Batman a solução, apenas o problema. Muitas vezes recebemos uma chamada de um administrador do EPM em pânico que sabe que preciso aplicar um patch, escrever um relatório e treinar duas pessoas. Eu sempre ouço isso pacientemente e depois peço ao cliente para descrever o problema como eles acabaram de descrever para mim a solução. Antes de pegar o telefone para chamar um especialista, pense primeiro em qual problema você gostaria de colocar na mesa deles.

Conclusão

Você realmente precisa usar o Batphone. Pergunte ao redor. Não pergunte apenas a um especialista em consultoria e não obtenha apenas uma solução possível. Pergunte a seus colegas ou outros na indústria quem eles sabem quem pode atender uma chamada batfone, e fale com pelo menos dois deles. É uma boa verificação de realidade para ver como um especialista versus outro pode lidar com o seu problema. Lembre-se, Batman pode ter sido incrível, mas há muitos super-heróis para escolher!

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).