Planear projectos no ambiente de Help Desk de TI

Tradução de post de Anna Halstead, PMP

Os serviços de Help Desk, no domínio do Suporte de TI, têm muitas vezes de proceder a preparações para fornecer suporte para uma nova ferramenta, aplicação, tecnologia ou produto que serão implementados para os seus utilizadores finais. Embora este tipo de projectos sejam normalmente pequenos e não complexos, todos os projectos de help desk devem ter um planeamento adequado e seguir uma estrutura de projecto, deforma a manter a satisfação do cliente e garantir que quaisquer mudanças no ambiente suportado, não tem um impacto negativo no serviço que o help desk fornece. Afinal, um dos propósitos chave do help desk na sua operação diária é garantir a satisfação do cliente através do fornecimento consistente do serviço acordado. Isto poderá estar em risco quando o suporte para uma nova tecnologia, ferramenta, aplicação ou produto é introduzido e o cliente fica insatisfeito com o serviço.

Estamos a falar de que tipo de projectos?

O projecto pode ser, por exemplo, entrada em produção uma aplicação de negócio para a companhia, migração de utilizadores finais para um cliente de email diferente ou actualização de uma nova versão de uma aplicação existente ou de uma tecnologia já em uso. Se forem estes os casos, as possibilidades são de que o suporte do Help Desk é só uma parte de um projecto maior e trans-departamental. Muitas vezes é onde as questões podem começar se o Gestor deste Projecto não está totalmente consciente da função que o Help Desk irá desempenhar ou assumir que não é necessário planeamento. Nestas circunstâncias, a prontidão do Help Desk pode ser sobrestimada, o que será extremamente frustrante para o pessoal envolvido e para os clientes. O gestor de projecto do Help Desk deverá assegurar-se que a globalidade da organização de TI está consciente doq eu faz ocall center e a função que desempenha quando fornece o suporte ao utilizador final.

Temos de fazer as perguntas certas desde o início. Para avaliar o âmbito e o impacto que o projecto vai ter no Help Desk e nos utilizadores finais.

Duas razões do fracasso dos projectos

As histórias de fracassos espectaculares abundam, mas nem sempre são vistas como aquilo que são – exemplos. Já ouvimos falar dum projecto que tinha 150.000 euros de orçamento inicial e só é fechado quando ultrapassou já 1.000.000 de euros. Ou um projecto para um novo sistema que devia ser entregue em Julho e que é finalmente posto em produção em Setembro, mas dois anos depois. Qual será a razão que persegue os projectos e os conduz a estes fracassos.

O culpado mais apontado, por muitos, é a deficiente estimação. Há uma anedota o comum que afirma que uma pessoa com perfil técnico tem muita dificuldade em estimar o custo do almoço, mesmo quando dispõe de uma ementa. Mas isto é, claro, um mito.

Há pessoas com baixas capacidades de estimação, mas mesmo quando as estimativas falham por cem por cento, o custo total não poderá ultrapassar o dobro do inicial. Se as contas estão bem-feitas! Isto não é o desejável, mas nada disto é comparável com as ultrapassagens que todos conhecemos em projectos que parecia serem todos muito sérios e com horizontes bem definidos. Lamentavelmente, na maioria deles estamos envolvidos porque de alguma forma estaremos envolvidos no pagamento de alguma coisa, já que a maioria esmagadora destes são projectos com dinheiros públicos.

Mas a má estimação não parece ser a justificação para desvios de 500 e mais por cento. De facto, muitas pessoas experientes conseguem estimar razoavelmente bem, e, na onda de um projecto grande, o optimismo de alguns estimadores equilibra-se com o pessimismo de outros. Embora existam muitas outras razões recorrentes para a falha dos projectos há duas que se salientam como principais e primárias: as alterações de âmbito e o planeamento fraco do projecto.

As alterações de âmbito são provavelmente a causa maior para o fracasso dos projectos. O problema com as alterações de âmbito não é somente porque aumentam o custo, mas porque adicionam o custo fora da proporção correspondente ao esforço aparente. Por exemplo, um projecto estimado a 20 milhões cresce até um projecto que, se tivesse sido planeado dessa forma do início, seria estimado em 40 milhões. Somos tentados a acreditar que o custo final do projecto será à volta de 40 milhões, mas muitas vezes será perto dos 80 ou 90 milhões, porque as alterações do âmbito perturbam o planeamento e o desenvolvimento do que estava já concluído, isso implica re-trabalho e , se o processo for suficientemente longo, podem comprometer a estrutura do projecto como se quisesse adicionar 5 andares a um prédio planeado para 10.

As alterações de âmbito são um problema por duas ordens de razões. (1) Quer o projecto não teve o seu âmbito definido desde o início ou o gestor de projecto falhou na gestão efectiva dos pedidos de alteração do âmbito. As alterações de âmbito são inevitáveis e não são necessariamente más. Só se tornam perigosas quando não são devidamente geridas, isto é, quando não são adequadamente definidas, avaliadas, acompanhadas e geridas.

A segunda causa de maior preocupação e causadora de fracasso dos projectos é o planeamento pobre e, em particular, a desconsideração das actividades de projecto durante o planeamento. Estas actividades não fazem parte das estimativas, elas não surgem no plano e não parece que tenham efeito no plano. Mas quando são necessárias podem provocar o caos. Por exemplo, um projecto em que é necessário realizar a formação de um grupo de utilizadores, mas que falha na definição e realização de uma actividade para criar os materiais de formação, irá ser a base de atrasos logo no momento em queo teria a possibilidade de realizar os benefícios.

Os projectos não têm de falhar! Quando um gestor de projecto experiente e as suas equipas tratam de forma séria o planeamento e a gestão das mudanças do âmbito os projectos geralmente cumprem com sucesso. Se quer trabalhar sossegadamente em projectos de sucesso e deixar os catastróficos para outros, aprenda a controlar estas partes essenciais da gestão dos projectos.

Análise de Risco do Projecto: O que é e porquê fazer?

Os planos de projecto são, evidentemente, acerca do futuro tudo o que trata do future tem certa incerteza associada. Quando se estima a duração da actividade em 5 dias está intrinsecamente assente que isto pode provavelmente não ser assim mesmo. Pode haver uma pequena quantidade de incerteza ou uma grande, mas alguma haverá com certeza.

Como resultado da incerteza acerca das durações das actividades, qualquer estimativa da data de conclusão do projecto é só isso, uma estimativa. Esta será válida tão só as estimativas das durações das actividades se verifiquem como verdadeiras. Como há sempre muitas actividades, é quase certo que muitas delas tomem menos tempo que o estimado enquanto outras levarão mais tempo que o estimado.

Assim, na realidade o fim do projecto é provável que não possa ser projectado de forma tão determinística como o CPM e o PERT, mas esteja, talvez, dentro de um limite de datas que se pode espalhar simetricamente à volta da estimativa. (Na realidade é pior do que isso. O uso de estimativas determinísticas também introduz um preconceito de tal forma que as estimativas tendem sistematicamente para serem optimistas.)

A Análise de Risco do Plano (Schedule Risk Analysis) é uma técnica que reconhece esta incerteza ao substituir a duração determinística para cada actividade pela distribuição representando os limites das durações prováveis. Existem métodos analíticos para processar as distribuições de probabilidade em casos simples, mas as redes de projecto são normalmente muito complicadas para que estes possam ser aplicados.

A solução é utilizar uma simulação Monte Carlo. Isto é como simular um evento da vida real através do lançamento de dados, só que isto é feito num computador. Os computadores podem gerar aquilo que é denominado como números pseudo-random. Não são verdadeiramente ao acaso, porque eles podem ser reproduzidos se alguém conhecer o mecanismo de geração: utilizando estes números pseudo-random, podemos gerar séries de distribuições desejadas e estas são usadas numa simulação Monte Carlo para simularem sistemas físicos sobre um grande número de cenários gerados ao acaso.

A simulação Monte carlo tem aplicações em muitas áreas. No contexto de uma rede de projecto, a simulação Monte Carlo:

Usa uma amostra da distribuição definida pelo utilizador para cada duração da actividade.

Faz uma análise de caminho crítico (CPM) com base nas durações da amostra.

Armazena os resultados desta análise de tempo (geralmente de uma forma sumária como um histograma).

Repete os passo de 1 a 3 várias centenas ou milhares de vezes.

No fim deste processo pode produzir histogramas representado a probabilidade das distribuições de qualquer resultado de interesse, que geralmente incluem datas mais cedo e mais tarde de início e datas de fim, folga livre e total e custo para cada actividade.

Como resultado, a data de fim estimado do projecto e outras milestones importantes são representadas por distribuições de probabilidade em vez de estimativas com um único ponto. Assim em vez de prever que o projecto será completado em determinada data – uma previsão que o mais certo é ser errada – podemos fazer previsões mais realistas tais como «há 90% de hipótese que o projecto termine até 31 de Maio.»

Mas, talvez a razão mais importante para fazer uma análise de risco é o equilíbrio anteriormente mencionado, que significa que uma estimativa de um só ponto da conclusão do projecto realizada através de um determinístico CPM ou PERT não está muitas vezes nem dentro dos limites representados pela distribuição probabilística produzida pela análise de risco. A razão para isto é um fenómeno denominado merge bias.

UM equilíbrio fundido (merge bias) ocorre sempre que dois ou mais caminhos convergem numa rede e a incerteza acerca das suas durações é tal que qualquer dele pode tornar-se crítico. Para ilustrar este equilíbrio fundido, considere uma actividade que só tem dois predecessores que correm em paralelo. Suponha que cada uma possa levar qualquer coisa como de 1 a 6 dias com probabilidade igual. E suponha, ainda, que elas não ocupam fracções de um dia. (Isto pode parecer um pouco artificial e até é. No entanto, isto permite que o ponto a ser feito por analogia com o lançamento de dados e sem nos envolver numa montanha de cálculo.)

A duração esperada para cada actividade individual é, claro, de 3,5 (já que 1+2+3+4+5+6 todos divididos por 6): mas qual é o tempo esperado para ambos para se concluírem? A tabela seguinte mostra todos os 36 resultados possíveis para o par de actividades, que pode ser simulado pelo lançamento de dois dados. (Assim , por exemplo, se a primeira levar 5 dias e a segunda só 3 dias. O tempo tomado por ambas para serem completadas é 5 dias e pode ser visto na tabela.

	1	2	3	4	5	6
1	1	2	3	4	5	6
2	2	2	3	4	5	6
3	3	3	3	4	5	6
4	4	4	4	4	5	6
5	5	5	5	5	5	6
6	6	6	6	6	6	6

Das 36 possibilidades, só uma tem 1 como máximo enquanto 11 têm 6 como máximo. Assim tendo só dois caminhos paralelos podemos ver que o tempo que leva a realizar ambas as actividades é provável que seja maior do que a estimativa determinística de 3,5 dias. Se fizermos as contas vemos que o valor esperado é na realidade quase 4,5 dias. Com 3 actividades paralelas, o valor esperado é quase de 5 dias e com 5 actividades é cerca de 5,4 dias. E com 10 é de 5,8 dias. A convergiram claramente para 6 conforme o nº de caminhos paralelos aumenta).

Outra forma de olhar para isto é declarar a Lei de Murphy de uma forma menos pessimista do que Murphy.

“Se houver muitas coisas que possam correr mal então pelo menos uma irá correr mal.”
Numa rede de projecto com caminhos paralelos, basta um caminho correr mal para atrasar a conclusão do projecto. (correr mal significa tão só durar mais do que o esperado. Isto não implica que foi feito algum erro, mas pode ser só o resultado da inevitável incerteza envolvida na estimativa original). É isto o merge bias.

“Nestes assuntos a única certeza é que nada é certo.”  (Plínio o Velho)