White paper O Batfone

O título deste white paper se refere à maneira como o comissário Gordon não pensava duas vezes antes de usar o Batfone sempre que a cidade de Gotham estava em perigo (na série de TV “Batman” da década de 1970).

Este white paper faz parte da nossa coluna “From the trenches” (Nas trincheiras). Ele relaciona a história fictícia da série “Batman” a como, durante a implementação de um EPM, nós às vezes desejamos ter acesso a um Batfone quando estamos com problemas. Também aborda muitas maneiras de evitar problemas durante a implementação.

Para baixar a versão do Word deste white paper, consulte O Batfone.

Para ver mais white papers, consulte os white papers da coluna "From the Trenches".

O Batfone

Em 1966, a série de TV Batman original foi ao ar. Embora tenha durado apenas 120 episódios, ela mudou para sempre nossa cultura. No mundo de Batman e Robin (interpretados por Adam West e Burt Ward), sempre havia uma solução do Batman para tudo. Fosse qual fosse o problema, o Batman teria a solução. O Batmóvel, a Batlancha, o Batcóptero e a Batcaverna, todos tinham o seu lugar. E se você precisasse de ajuda, por mais complicada que fosse a situação, como poderia chamar o Batman? Ora, com o Batfone, é claro! Era só ligar e a ajuda já estaria a caminho.

Imagem de um Batphone vermelho (a partir da série de TV, "Batman"

O comissário Gordon recorria ao Batfone sempre que tudo parecia estar perdido, o que naturalmente acontecia em todos os episódios. Não importava a gravidade da ameaça: bastava pegar o Batfone e em 22 minutos (mais o tempo dos comerciais), o vilão estaria derrotado e a paz restaurada na cidade de Gotham.

Todas as soluções do mundo de Batman precisavam ter a forma de um morcego. Algemas? Em formato de morcego. Cinto de utilidades? Com logotipos de morcego. Gancho de escalada? Imitava asas de morcego, óbvio. Para minha surpresa, quando fui buscar imagens do Batfone, vi que ele parecia estranhamente normal. Um telefone vermelho de disco (lembram-se desses)? Não sei para quê o disco. As chamadas eram para um só lugar: A Batcaverna, onde a salvação estava ao alcance das mãos.

Por mais nostálgico que seja pensar em telefones de disco e episódios antigos da série do Batman, este não é o objetivo do artigo de hoje. Há 40 anos que o Batfone foi aposentado, mas todos os dias consultores de EPM recebem telefonemas de pessoas que têm a esperança de que ele vá funcionar uma última vez.

São vários os vilões que elas querem combater. Alguns são técnicos; elas precisam fazer uma atualização da versão x para a versão y. Alguns são de arquitetura; elas precisam fazer seu sistema de EPM interno se comunicar com usuários externos. Alguns são culturais; os usuários se recusam a usar o sistema. E outros são de procedimento; o processo que elas estão executando não parece oferecer o resultado esperado.

Não importa qual seja o problema, a solicitação para a empresa de consultoria é sempre a mesma: você consegue resolver em 22 minutos?

Esse tipo de situação é muito comum para um número surpreendente de usuários de EPM, uma situação em que eles precisam de ajuda para resolverem uma situação difícil. É geralmente uma emergência, e a solução exigida pela gerência para ontem. As pessoas que fazem essas chamadas (recebo algumas delas todas as semanas) não são nada bobas. São gerentes muito inteligentes, eficazes e bem-sucedidos.

Mas, obviamente, o Batfone não existe. Bem que eu queria que ele existisse. Eu o usaria para todo o tipo de problema pessoal. Portanto, as pessoas que fazem essas chamadas dificilmente ficam satisfeitas com as respostas que recebem. Então, vamos parar um pouco para conversar sobre como as pessoas acabam caindo em situações tão difíceis que sentem necessidade de recorrer ao telefone vermelho, e como você pode evitar ser uma delas.

Entrando em apuros

Primeiro vamos falar sobre como as pessoas entram em apuros durante a implementação de um EPM. Há algumas causas comuns:

  • Subestimar o desafio    Esse é, sem dúvida, o erro mais comum durante a implantação de um EPM. Isso não quer dizer que todas as implantações precisem ser longas e árduas. Certamente nem sempre é assim. Mas, talvez por conta de expectativas irrealistas, é incrivelmente comum subestimar o trabalho necessário para se obter os benefícios da implantação de um EPM. O primeiro erro de subestimação ocorre na escolha do objetivo. Algumas pessoas consideram a instalação de uma ferramenta um projeto bem-sucedido. Isso não é verdade, é claro. Outras consideram a primeira utilização da ferramenta ou o primeiro relatório gerado por ela como o objetivo. Também não é o caso. A resolução de quaisquer problemas que as ferramentas de EPM tenham sido escolhidas para abordar deve ser a sua meta. Isso significa que a cultura mudou, o treinamento foi concluído, o sistema está em uso, as ferramentas estão funcionando e os dados estão ali. Sim, isso pode ser uma grande coisa, mas mesmo que esteja a um centímetro deste objetivo, você ainda não tem nada. (Bem, quase nada.)

  • Transformar a implantação em um projeto técnico    Nós que estamos no setor de tecnologia somos os mais culpados disso e, sinceramente, a maioria de nós sabe que não deveria ser assim Apesar disso, é difícil resistir à tentação de acreditar que a disponibilidade da tecnologia significa que o problema está resolvido. Muitas organizações que visitamos dizem alguma variação do seguinte: “mas nós instalamos o Project Server, por que nossa equipe está sobrecarregada?”. Conforme temos dito há algum tempo, fazer o gerenciamento de projetos corporativos dar certo é uma combinação de pessoas, tecnologia e processo e uma boa medida de gerenciamento de alterações para completar. Isso tudo não vem automaticamente junto com o DVD do software quando ele chega pelo correio.

  • Não envolver a gerência    Isso também acontece com muita frequência. Afinal, as pessoas que melhor compreendem os benefícios de um gerenciamento de projeto corporativo são provavelmente aquelas que estão tendo problemas em analisar a grande quantidade de dados gerados por um ambiente com vários projetos e vários recursos. O gerenciamento de projetos corporativos faz mais sucesso quando uma organização tenta conciliar um conjunto complexo de prioridades conflitantes e uma grande combinação de habilidades e experiências. Você talvez pense que o gerenciamento seria parte natural de um projeto desse tipo, mas nem sempre é assim. Alterar a cultura corporativa, passando da mentalidade do projeto individual para a mentalidade do projeto corporativo é um desafio quase impossível sem a gerência. Mesmo assim, muitas vezes a gerência é evitada por medo de que ela não saberá reconhecer o que será preciso para concluir a implantação de um EPM.

  • Elaborar cronogramas irrealistas    Ninguém deseja que a implantação de um EPM seja demorada. E é comum esperarmos que o projeto possa ser realizado em dias ou algumas semanas, em vez de meses, como é mais normal. Há também o desafio muito comum de não obter recursos para um projeto “interno” como um EPM tão rapidamente quanto para projetos baseados em clientes ou comerciais. Por esses e outros motivos, costumamos elaborar um cronograma de projeto com requisitos de recursos lamentavelmente insuficientes.

  • Não atribuir gerenciamento de projetos ao sistema de gerenciamento de projetos    Se você já leu qualquer coisa que eu escrevi, provavelmente já me viu falar disso antes. Os gerentes de projetos são suscetíveis à síndrome da “casa de ferreiro, espeto de pau”. O resultado é, no geral, uma falta de um estatuto do projeto, um orçamento aprovado, um cronograma controlado, recursos dedicados e todos os demais requisitos para o projeto em si que são comuns a todos os outros projetos gerenciados por eles.

O que eles estavam esperando?

Ok, é por isso que as pessoas entram em apuros com tanta frequência. Os benefícios que a gerência espera obter da implantação de um sistema EPM geralmente estão diretamente relacionados a desafios comerciais. É a promessa de solucionar esses desafios que faz a gerência aprovar as despesas com software, hardware, infraestrutura e possivelmente até serviços. Os mais comuns desses desafios podem soar familiares:

  • Os recursos estão sobrecarregados   Por mais que não esteja claro em que os recursos estão sendo gastos, é muito comum descobrir que eles estão sobrecarregados. Um problema mais complexo é descobrir que alguns recursos estão sobrecarregados, enquanto outros estão subcarregados, o que geralmente indica uma incompatibilidade entre as habilidades e a experiência disponíveis e aquelas exigidas.

  • Projetos importantes não estão sendo concluídos no prazo    Deveria ser óbvio que projetos críticos devem ser concluídos dentro do prazo, mas a vida parece atrapalhar tais planos. A causa pode ser requisitos de recursos conflitantes, escolher projetos demais que exijam muito das mesmas habilidades, ou simplesmente má priorização. Às vezes, as organizações pensarão que isso revela falta de habilidade do gerente de projeto, mas em um ambiente matricial, com múltiplos projetos e departamentos, é mais provável que o problema seja de natureza organizacional.

  • Projetos não estão sendo concluídos dentro do orçamento    O que acontece com o cronograma pode se aplicar igualmente aos custos. No setor da alta tecnologia, bem como em muitos outros setores, o componente mais variável do custo de um projeto é a quantidade de trabalho aplicado a ele. Se as mesmas pessoas continuarem por muito tempo em um projeto, você estará adicionando custos a esse projeto. Um número surpreendente de projetos administrativos permanece não controlado. Eles estão planejados, mas não há registros do custo real por projeto.

  • A concorrência está concluindo projetos mais rapidamente do que você    Em uma economia competitiva, ser o primeiro no mercado pode fazer a diferença entre a sobrevivência e o esquecimento. Portanto, para muitas organizações, certificar-se de que o seu gerenciamento de projetos é pelo menos tão eficaz quanto o de seus concorrentes é importante.

  • Não há como saber em que os recursos dos projetos estão gastando seu tempo, ou quanto tempo está sendo utilizado em cada projeto    Às vezes, nenhuma resposta é pior do que uma resposta incorreta. Se você faz parte da equipe de gerenciamento sênior, isso é especialmente verdadeiro. Se souber que os resultados são ruins, pode aplicar as habilidades e recursos à sua disposição para solucionar o problema em questão. Se souber que algo está errado, mas não consegue identificar o que é, você está de mãos atadas. Quando não tenho como saber por onde começar a consertar algo,

como posso evitar ter problemas?

Você não quer nunca chegar ao ponto em que sente que precisa de um Batfone. Então, o que você pode fazer com seu ambiente de EPM para garantir que isso não aconteça?

Certo, tudo o que dissemos na primeira seção é óbvio:

  • Faça uma boa estimativa

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

  • Envolva a gerência sênior desde o início

  • Elabore um cronograma realista e verifique se ele reflete a realidade comparando-o com outros no setor.

  • Elabore um cronograma de projeto e um estatuto de projeto e faça tudo o que normalmente faria com outros projetos.

O que mais você pode fazer?

Em primeiro lugar, inicie o projeto reconhecendo que em algum momento no futuro você vai querer usar o Batfone. Isso é fato. Com isso em mente, o que pode fazer é um orçamento de assistência para o qual não há nenhum plano no momento. Recomendamos que nossos clientes separem de 10% a 20% do orçamento do projeto para "requisitos não alocados". "Para que serve isso?", é o que sempre nos perguntam. E sempre respondemos: “Depois vocês nos dizem”. Normalmente, nem todo esse dinheiro é usado. Mas também é incrivelmente comum que parte dele seja. Ter um especialista qualificado já alocado e orçamento para o seu projeto faz uma grande diferença mais tarde.

Comece com a expectativa de que o plano e as pessoas mudarão. Minha citação favorita sobre gerenciamento de projetos é de Napoleão Bonaparte, que disse: "qualquer plano de batalha só dura até o contato com o inimigo." Isso também se aplica a planos de EPM. Considerando que uma implementação provavelmente se estenderá por vários meses, as chances de que parte da equipe mude durante o processo é muito grande. Portanto, esteja pronto para redundância.

Sistemas EPM evoluem. É comum atualmente pensar no “custo total de propriedade” em relação a um aplicativo empresarial. Acredito que deveríamos incluir o ciclo de vida total do aplicativo em nossos planos de projeto de EPM. Você já pensou em que versão da ferramenta está prestes a implementar? De que outras ferramentas ela depende para funcionar? E quanto à atualização sistemática dessas ferramentas? Você realizou personalizações? E quanto ao treinamento personalizado? Você pensou em como esses aspectos migrarão para uma nova versão se ela for implantada?

Planeje também a redundância dos seus especialistas. Se tiver apenas um consultor trabalhando para você, o que acontecerá daqui a alguns meses quando você passar para uma nova fase da implementação ou introduzir um novo membro fundamental na equipe? Esse consultor estará disponível? (Consultores migram de um projeto para o outro, de modo que a resposta é geralmente "não".) Se você trabalha com uma empresa de consultoria, já conversou sobre como eles podem preservar o trabalho da sua equipe para que outras pessoas possam replicá-lo, se necessário?

Coloque no papel

Um dos desafios mais comuns e fáceis de solucionar é causado por má documentação. Este é o elemento mais fácil de subestimar de todos, mas a existência desse tipo de documentação pode representar a diferença entre consultar uma referência por escrito e sair à procura do Batfone. Também não adianta nada apenas redigir um documento e enfiá-lo em uma gaveta qualquer. 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 sistemático. Considero os documentos seguintes alguns dos mais importantes para um ambiente de EPM:

  • Caso comercial    Não sei o que torna o caso comercial original tão desestimulante, mas ele é a coisa mais comum de se perder de vista, mesmo que em muitos aspectos seja o motivo fundamental que o levou a ter um ambiente de EPM para início de conversa. O caso comercial especifica quais são os benefícios organizacionais esperados; o que a organização espera do sistema EPM? Quando recebemos uma Batchamada, uma das primeiras coisas que perguntamos é: “o que sistema deveria estar oferecendo a vocês?” Não perguntamos apenas ao administrador. Perguntamos também à gerência, aos usuários e aos beneficiários comerciais. O mais comum é recebermos uma resposta diferente de cada uma das partes. Isso acontece porque a premissa comercial original se perdeu.

  • Funções e responsabilidades    Na versão final do documento de funções e responsabilidades, nós geralmente decidimos pelo nome de um indivíduo, mas não demora muito para o papel que este indivíduo desempenha no sistema EPM seja esquecido. Manter um documento de funções e responsabilidades permitirá que você ajuste os parâmetros de quem faz o quê no processo de EPM, à medida que a organização passa naturalmente por mudanças de pessoal ou até mesmo alterações estruturais.

  • Guias de processo e fluxograma    Isso geralmente é esquecido quando chegamos aos manuais de procedimento. As pessoas se veem diante do passo a passo em um manual de procedimento, mas sem terem um contexto de porque esses passos são importantes e o que devemos fazer com o resultado de cada um deles. Um guia de processo e, melhor ainda, um fluxograma visual permitirão a futuros gerentes entenderem o que o sistema oferece e facilitarão ainda mais sua adaptação no futuro.

  • Critérios de seleção do sistema    Quando você escolhe seu sistema de EPM e quaisquer ferramentas de terceiros que possa ter selecionado ao longo do processo, deixe claro para gerações futuras em que se baseou sua decisão. Nós já visitamos organizações 5, 7 ou até 10 anos depois de um sistema ser implantado, vimos um sistema com várias ferramentas associadas a ele e perguntamos: “Por que vocês estão fazendo isso? Seria muito mais fácil fazer deste outro jeito!" Não havia nenhum registro dos motivos que levaram a tais decisões. Em alguns casos, o cliente havia passado anos fazendo algo de maneira extremamente complicada, e que poderia ser feito de modo muito mais simples com versões atuais das ferramentas existentes. Mas não podia tomar a simples decisão de mudar de ferramenta ou usar uma versão mais atual porque já não tinha acesso aos motivos que o levaram a decidir fazer algo de uma determinada maneira anos atrás.

O Batfone realmente não existe.

Quando digo isso, parece que estou dizendo que o Coelhinho da Páscoa e o Papai Noel não existem. É uma má notícia, eu sei. Mas, sério, o Batfone não existe. Tenho certeza, no entanto, que a simples inexistência deste telefone mágico não impedirá as pessoas de me telefonarem amanhã me pedindo para eliminar o mais recente vilão da cidade de Gotham. Se você estiver em apuros e sentir necessidade de telefonar para um especialista, tenha as seguintes recomendações em mente:

  1. Ouça os conselhos que eles têm para lhe dar. Não faz sentido pagar pela consultoria de um especialista e então decidir que você sabe mais do que ele sobre o assunto. Se pretende pedir conselhos e está falando com um especialista, tente ouvir e pelo menos levar em consideração o que ele tem a dizer. Batman não teria continuado a aparecer para ajudar o comissário Gordon repetidamente se todas as vezes Gordon falasse para ele: “agora que está aqui, Batman, por favor, faça a mesma coisa que todos os meus outros policiais fazem”.

  2. Batman conseguia resolver o problema em 22 minutos, mas você provavelmente não vai conseguir. Se for telefonar para um especialista, deixe que ele lhe diga quanto tempo deve demorar para solucionar seu problema. Você pode decidir não adotar a solução depois que ele terminar, mas superar desafios de EPM, mesmo que eles sejam técnicos, dificilmente leva apenas alguns minutos. Afinal, Batman tinha que resolver tudo em 22 minutos porque 8 minutos eram dedicados aos comerciais, e eles são essenciais.

  3. O comissário Gordon nunca dizia ao Batman qual era a solução, apenas qual era o problema. É muito comum recebermos um telefona de um administrador de EPM em pânico, que já sabe que eu devo aplicar um patch, escrever um relatório e treinar duas pessoas. Sempre ouço tudo isso pacientemente e então peço para o cliente descrever o problema da mesma forma que ele me descreveu a solução. Antes de apanhar o telefone e ligar para um especialista, pense primeiro sobre qual é o problema que pretende apresentar a ele.

Conclusão

Você realmente precisa usar o Batfone. Pergunte por todo o lado. Não fale apenas com um consultor especializado, e não se contente com apenas uma solução possível. Pergunte a seus colegas e outras pessoas do ramo se eles conhecem alguém que possa receber uma Batchamada, e converse com pelo menos duas dessas pessoas. Nada melhor do que ver como dois especialistas diferentes lidariam com um problema para ter uma visão real dele. Lembre-se que o Batman pode ser incrível, mas você tem muitos outros super-heróis à sua escolha!

Sobre o autor

Chris Vandersluis é presidente e fundador da HMS Software, com base em Montreal, Canadá, um parceiro certificado da Microsoft. Ele é formado em Economia pela McGill University e tem mais de 30 anos de experiência em automação de sistemas de controle de projetos. Membro do Project Management Institute (PMI), ele participou da fundação dos capítulos de Montreal, Toronto e Quebec do Microsoft Project Users Group (MPUG). As publicações para as quais Chris já escreveu incluem a Fortune, a Heavy Construction News, a Computing Canada e a PMNetwork, além de ser colunista regular da Project Times. Professor de Gerenciamento Avançado de Projetos na McGill University, frequentemente dá palestras sobre as funções da associação de gerenciamento de projetos na América do Norte e no mundo. A HMS Software é a fornecedora do sistema TimeControl de controle de horas orientado para projetos e tem sido Parceira de Soluções de Projetos da Microsoft desde 1995.

Chris Vandersluis pode ser contatado pelo email: chris.vandersluis@hms.ca.

Se quiser ler mais artigos relacionados a Gerenciamento de projetos corporativos (EPM) de Chris Vandersluis, consulte o site da HMS (http://www.epmguidance.com/?page_id=39).

Expanda suas habilidades
Explore o treinamento
Obtenha novos recursos primeiro
Ingressar no Office Insider

Essas informações foram úteis?

Obrigado por seus comentários!

Agradecemos pelos seus comentários! Parece que pode ser útil conectar você a um de nossos agentes de suporte do Office.

×