Quando o projecto corre mal

Estava tudo a correr suavemente e bem quando, de repente, verifica que está atrasado e acima do orçamento e sem fim à vista. Para voltar ao caminho necessita cumprir um processo. Proponho-lhe 8 passos neste processo.

1. Avaliação:

A primeira coisa que tem de fazer é pesquisar até que ponto está fora do caminho. Exactamente, quantos dias está atrasado relativamente ao planeado e o que é isso em % da linha de tempo? Também, quanto está acima do orçamento e o que significa isso em % do orçamento global?

2. Re-planear:

De seguida reveja o seu Plano do Projecto, para verificar se consegue recuperar tempo através de mudanças nas atribuições das actividades. Primeiro, veja se pode realocar pessoas a actividades de forma mais expedita poupando tempo. Em seguida, verifique as dependências das actividades e veja se há uma sequência mais lógica que consiga completar mais cedo os prazos. Assegure-se que identifica o caminho crítico no seu plano para que saiba que actividades devem ser concluídas e quais são secundárias. Assim, atribua os seus melhores recursos às actividades críticas e tente concluí-las mais cedo. Todo o tempo que consiga poupar através do replaneamento vai-lhe ser precioso.

3. Brainstorm:

Reúna-se com a sua equipa e reveja o plano replaneado e verifique se em conjunto conseguem obter novas ideias para realizar o projecto mais cedo ou poupar no orçamento. Pode até ficar surpreendido com os resultados que obtém.

4. Diminuir o âmbito:

A forma mais fácil de voltar a colocar o projecto no caminho certo é diminuir o âmbito. Isto significa realizar menos que o previsto originalmente. Faça uma lista dos resultados do seu projecto, priorize-os em relação com os objectivos do projecto e veja se há alguns resultados que possa, com a autorização do Sponsor do Projecto, remover do âmbito do projecto, para o ajudar a voltar ao caminho. Não significa que estes resultados deixam de ser produzidos, antes que poderão vir a ser feitos como actividades isoladas após a conclusão do projecto.

5. Peça ajuda:

Se o seu Sponsor não pretende alterar o âmbito do projecto, então peça-lhe por uma extensão do prazo ou por mais orçamento para que possa atribuir mais recursos para concluir dentro do prazo. Obtenha o seu apoio informando-os do seu atraso. Seja honesto e frontal. Mostre que está disposto a fazer tudo para estar em condições de cumprir o prazo estabelecido, mas que necessita de apoio para isso. Com este apoio tudo é possível.

6. Controle a mudança:

Agora tem de controlar de forma apertada a mudança para que novas funcionalidades ou resultados não sejam adicionadas sem a sua aprovação. A mudança é comum na maioria dos projectos o que o obriga a controlá-la para garantir a oportunidade de sucesso.

7. Reunião:

Realize uma reunião com a equipa para explicar porque é que o projecto está atrasado e a importância dele. Obtenha o apoio deles para trabalharem com empenho e mais horas de forma a serem capazes de o realizar em tempo. Lembre-se que necessita da compreensão de todos e adesão para poder acabar em tempo e dentro do orçamento.

8. Comunique:

Mantenha todos informados do progresso com regularidade. Desta forma manter-se-ão focados e motivados para alcançar os objectivos estabelecidos.

Compreender o Workflow ITIL

Muitas companhias começam a sua implementação ITIL com a função Service Desk e os processos de Gestão de Incidente e Problema. O seguinte exemplo mostra como estes grupos podem trabalhar em conjunto.

Call Center – o Serviço de Call Center redirecciona as chamadas para o apropriado Service Desk ou membro do Service Desk com base nos atributos da chamada. Por exemplo, um utilizador requer assistência na utilização de uma aplicação. Esta chamada é redireccionada pelo Call Center para o agente apropriado no Service Desk.

Service Desk – O agente do Service Desk toma a propriedade do Incidente. Regista o Incidente em preparação de realizar suporte directo ao utilizador, este membro do Service Desk de forma segura realiza as actividades estabelecidas no processo de Gestão de Incidente.

Gestão de Incidente – O agente, torna-se um operador de Incidente no âmbito do processo de Gestão de Incidentes, recolhe a informação e tenta verificar a triagem com o utilizador. Se o agente for incapaz de assistir o utilizador, pode escalar ou abrir um registo de Problema.

Escalar o Incidente

A Escalação é outro ponto de confusão em muitas organizações que planeiam para ITIL. Quando o primeiro nível de tratamento esgota todas as fontes de informação disponíveis e determina que é provável que não seja capaz de concluir dentro da linha de tempo ou é-lhe impossível assistir o utilizador, então o Incidente deve ser encaminhado para outra pessoa (2º nível) ou aberto um Problema.

Assumindo encaminhamento do Incidente para um 2º nível, o agente continua a desempenhar actividades na base da Gestão de Incidentes. A pessoa do 2º nível de Incidente pode residir fisicamente em qualquer sítio, seja num departamento de TI ou mesmo fora da organização, mas desde que trabalhe sobre o Incidente, estará a trabalhar na dependência e controlo da Gestão de Incidentes.

Não há nenhum requisito de que qualquer nível de suporte para além do agente do Service Desk (p. ex. 2º, 3º, etc.) faça parte de qualquer função ou departamento e qualquer linha de suporte pode realizar investigações talvez até com a utilização de procedimentos de teste, ferramentas de diagnóstico, etc.

Como exemplo, na dependência de um Incidente, o segundo nível poderá ser um técnico no grupo de redes ou um administrador que trabalha no departamento de comunicações. É o trabalho realizado, não a estrutura de reporting organizacional que interessa. Isto exige muitas vezes a existência de Acordos de Nível Operacional (OLA – Operational Level Agreements) entre as TI e vários processos, bem como grupos funcionais.

No nosso exemplo continua a ser a rotina do trabalho do dia-a-dia e considerado, contudo, um Incidente. Se o segundo nível determina que não é provável solucionar ou é incapaz de resolver a questão, pode então ser escalado. O número de níveis de suporte é indefinido, sendo único para cada infra-estrutura da companhia ou organização. Não é incomum existirem dois, três ou quatro níveis de Suporte a Incidentes cada um com crescente foco em conhecimento e experiência.

Gestão de Problemas

Em qualquer momento, se parece que a questão é tão complexa ou que exige o envolvimento de múltiplos departamentos tecnológicos ou silos, o Incidente pode exigir a criação de um registo de Problema. Algumas organizações escolhem levantar um Problema sempre que um Incidente não possa ser encontrado na Base de Conhecimento.

Quando trabalha com um Registo de Problema, a equipa passa a trabalhar sob o controlo do processo de Gestão de Problemas. Este exige a nomeação de um “Gestor de Problemas” ou um “Coordenador de Problemas” para liderar o trabalho e supervisionar as interacções entre departamentos.

È neste ponto que é formada uma “equipa de Problema” de técnicos de vários grupos técnicos. Os técnicos do Service Desk (que realizam o suporte de 1º nível no tratamento de Incidentes) tomam agora a responsabilidade de supervisão e monitorização da resolução do Problema, coordenando com o líder da equipa de problema e mantendo o utilizador ou cliente informado conforme for requerido.

Sumário

Precisamente são estas funções e as suas responsabilidades que criam o processo. Como pudemos ver nestes exemplos, a estruturação para os processos nem sempre exige a reorganização dos departamentos. Mas exige muitas vezes formação e organização de equipas dinâmicas para que saibam como e quando devem actuar (por exemplo, Utilização de Scripts para a Gestão de Incidentes) e podem, ainda exigir Acordos de Nível Organizacionais.

Processos e Performance

A estrutura organizacional tem um papel significativo no sucesso ou fracasso da adopção da ITIL. Uma correcta estrutura organizacional é crítica para o seu sucesso … mas provavelmente não deverá reorganizar para a alcançar.
Embora muitos líderes percebam que a estrutura organizacional afecta a capacidade das TI de obter a performance exigida, já muitas vezes ficam confundidos quando as alterações efectuadas para esse efeito não devolvem os resultados esperados.
Em 2006, a Gartner previu que 45% dos realinhamentos organizacionais das TI iriam falhar devido à confusão entre processo e performance. Esta confusão acerca da estrutura, por sua vez, gera resistência dentro das organizações. No mesmo ano de 2006, um estudo realizado sobre as barreiras para a adopção da ITIL encontrou 72% das resposta a apontar para a resistência organizacional.
A tentativa de mapear os processos ITIL de forma funcional, ou seja um grupo de Incidentes, um grupo de Problemas, e por aí fora, rapidamente verifica-se problemático. Os processos descrevem o trabalho realizado por pessoas, não as estruturas organizacionais.

Processo vs. Performance

A estrutura organizacional tradicional das TI faz pouca distinção entre processo (descrição das actividades) e performance (execução das actividades.
A estrutura tradicional das TI é baseada num silo, com a especialização técnica concentrada em unidades organizacionais auto-contidas. Esta estrutura em silo é uma herança das operações de TI iniciais, que coleccionavam a tecnologia os seus tecnólogos em unidades geríveis.
Por exemplo, o departamento de telefones operava os sistemas de telefones, forneciam suporte aos utilizadores e realizavam a manutenção dos sistemas. O departamento do mainframe faz o mesmo, bem como o departamento de redes, etc. Cada silo tem as suas próprias versões de processos similares e não há nunca muita coordenação entre estes silos.
Não há nada de errado com a existência de silos e eles existem na maioria das organizações e profissões. A utilização de silos é usada para coleccionar especialistas em unidades geríveis.
Contudo, enquanto o âmbito das TI expandiu-se muito para além de sistemas isolados e desligados, a gestão em silo não acompanhou o progresso. Os serviços de TI dos nossos dias são sistemas complexos de comunicação e colaboração atravessando múltiplos silos. Esta expansão dos serviços de TI é a causa do dilema com que nos defrontamos para uma operação orientada aos processos.
Para visualizar uma organização efectiva a utilizar operação dirigida ao processo com equipas dinâmicas compostas por recursos provenientes de localizações variadas, considere a forma como opera tipicamente um quartel de bombeiros:

1. Os seus membros realizam os seus empregos regulares até que ouvem o alarme de incêndio; nessa altura reúnem-se no quartel.
   
2. Cada bombeiro conhece a sua função – um toma o comando, outro dá o arranque do carro e outros recolhem e carregam as ferramentas.
   
3. Todos conhecem o seu trabalho e não há confusão acerca de quem é que faz o quê, quando, como ou porquê.
   
4. A trabalhar em conjunto apagam o fogo.
   
5. Quando o fogo está extinto, regressam ao quartel para limpar o equipamento e completar a documentação.
   
6. Então regressam aos seus empregos e esperam por nova chamada.

Embora seja inevitável alguma mudança organizacional para suportar as TI modernas, a verdadeira mudança não está onde se sentam os técnicos de TI ou a quem eles reportam. A mudança real é em como eles se organizam dinamicamente e colaboram para alcançar um objectivo – tal como a analogia dos bombeiros voluntários.
Ver mais em How to Organize ITIL