de IT Skeptic
Há uma visão essencial que poucas vezes é referenciada na ITIL e ainda menos vezes compreendida que é a Gestão do Portfólio de Serviços.
Como trabalhamos numa área em que defendemos, vendemos e implementamos processos e soluções de Gestão de Portfólio e de Projetos este artigo saltou-nos à vista e decidimos traduzi-lo com mínimas adaptações. Corresponde a uma visão integrada destes fenómenos que partilhamos.
Demasiadas organizações têm uma visão portfólio em que apreciam apenas programas e projetos, enquanto negligenciam os sistemas em operação. Este é uma ordem removida de uma visão verdadeiramente holística. A Gestão de Portfólio e de Projetos só olha para a mudança, e não para o status atual. A Gestão de Portfólio de Serviços (SPM) olha para os serviços em produção bem como às propostas mudanças de serviço.
SPM olha para os serviços em produção, bem como as alterações propostas ao serviço. Olha para a distribuição de recursos entre ambos o Construir (Build) e o Executar (Run), e não apenas Construir. O SPM considera o impacto sobre os nossos serviços existentes quando tentamos introduzir novos serviços. Esta é uma abordagem brilhante. É essencial. Não fazer isso é a razão por que muitos departamentos de TI estão sempre afogados em projetos.
A incapacidade de gerir todo o portfólio de serviços correntes e planeados - concentrando-se apenas na carteira de mudança - significa que haverá um dilúvio contínuo das despesas de investimento (CAPEX) sobre os novos serviços com zero de consideração da capacidade de RUN para os absorver (e muitas vezes, orçamento de zero para os fazer).
Este martelar teimoso é agravado pela prática moderna de retirar os recursos para fora do RUN e atribuí-los aos projetos sem considerar adequadamente o impacto sobre o RUN. Nós entramos em autofagia e consumimos os nossos recursos, destruímos a nossa capacidade de realizar os serviços, porque estamos tão ocupados em construir e mudar os serviços.
O balanceamento de prioridades e recursos em todo o portfólio de mudança, de projetos e de programas, não é suficiente. Temos de equilibrar entre todas as atividades, através BUIL e RUN em conjunto. A Estratégia de Serviço ITIL diz-nos isso através do SPM. É uma pena, poucas pessoas o leiam e menos ainda o tenham obtido. A gestão do Serviço de TI é um equilíbrio constante entre o BUILD e o RUN, ou como eu gosto de definir para proteger e servir (OK OK talvez isso não seja o melhor slogan para usar agora, mas aceitem a ideia).
Em muitas organizações, o PPM é tratado como uma prática estratégica e ferramentas de PPM são vendidas para os executivos. PPM não é estratégico: é uma tática para o PMO da Empresa gerir as tarefas que lhe foram dadas com as técnicas que criaram. Por outro lado, a Gestão do Portfólio de Serviço, este é que é estratégico.
Espere! Ainda há mais. A Gestão do Portfólio de Serviços oferece uma visão holística de tudo o que acontece na área de TI. Pense nisto: isso faz com que o SPM seja um dos principais mecanismos de comunicação entre a empresa e as TI. O SPM é como nas TI articulamos a nossa posição, a nossa capacidade, os nossos desafios, as nossas necessidades em termos de negócio. O SPM é como solicitamos decisões e direção do executivo e da governação e seus pares sobre como alocar o nosso esforço e os nossos recursos. É como justificamos mais recursos.
Qual é o mais importante desafio para as TI no momento? Sem dúvida que é a falta de uma boa governação de TI (a menos que seja um fornecedor a contar a história, caso em que o maior problema é, naturalmente, qualquer que seja que a sua ferramenta resolve ou pode ser feito para parecer resolver). Esta é uma questão tão importante!
Se a governação das TI é o desafio e questão mais importante, então o SPM é uma das mais importantes práticas e o portfólio de serviços um dos artefactos mais essenciais. Então porque é tão raro?
Ver em Inglês aqui.
Abaixo descrevemos algumas das áreas que devem ser averiguadas (ou pelo menos visitadas) para verificar se existem alguns riscos escondidos ao longo de todo o projecto. Pode funcionar como um embrião para a criação de um Registo de Riscos para utilizar em projectos. Então aqui vai:
Riscos relativos ao Âmbito – Deslizar potencial do âmbito porque os requisitos do projecto não estão definidos com clareza. Foi bem definido o critério de performance? Estão definidas todas as condições limite? Onde começa e acaba o trabalho? Foram definidas as responsabilidades de todas as partes nas diferentes fases do projecto? Foram definidos os procedimentos de gestão da mudança do âmbito?
Riscos relacionados com o Plano e o Esforço – O deslizar do âmbito é um risco de grande dimensão para o plano e o custo mas estimativas de qualidade pobres são também um factor significativo. A falta de experiência anterior. Conhecimento experimentado da área de actividade, falta de adequadas revisões e verificações são as causas para estimativas inexactas. Ser pessimista faz-nos ganhar pontos e devemos quase ser paranóicos quando se trata da estimação do projecto. O optimismo mata, muitas vezes!
Riscos relacionados com Assumpções – Será que definimos com clareza todas as assumpções do projecto na especificação de trabalhos? E elas cobrem todos os aspectos importantes e as fases do projecto? Já foram documentadas as actividades a realizar se uma assumpção se comprovar como errada e evolui para ser um risco para o projecto? Já fez a revisão com o cliente / sponsor as assumpções e as contingências para cada uma? Todas as assumpções, num projecto ideal, devem ser registadas e visitadas em cada relatório de status e revisão de projecto
Riscos relacionados com Dependências – O projecto está dependente de stakeholders múltiplos como, por exemplo, cliente / sponsor, fornecedores, empreiteiros, agências externas, etc. e para cada dependência irão existir riscos associados. Teremos de garantir que todas as dependências são documentadas e que: estão registadas as entregas que devem ser realizadas por cada parte? Garanta que as linhas de tempo para as entregas de cada parte estão claras para todos e comprometidas? E mencionou neste compromisso qual é a contingência se se materializar o risco e o compromisso não é alcançado pelo stakeholder? Todas as dependências devem ser registadas e visitadas nos relatórios de status e nas revisões do projecto. Alguns exemplos destes riscos são – atraso do fornecedor, problemas de entregas, questões com empreiteiros, atrasos do cliente, atrasos de envio, etc.
Riscos relacionados com Constrangimentos – Quase todos os projectos têm algum tipo de constrangimento. O exemplo deste constrangimento pode ser limitados recursos para a execução, elevado custo dos produtos envolvidos, tempo de execução muito apertado, condições apertadas de extensas de garantia, etc.
Riscos relacionados com a Tecnologia – A tecnologia seleccionada pode colocar riscos em dependência das suas limitações. Isto é especialmente verdade se a tecnologia é recente e pouco comprovada ou não é conhecida se for necessário suporte técnico. A limitação da tecnologia pode ainda inibir a interoperabilidade futura entre sistemas. A mesma tecnologia pode colocar problemas se estamos ainda a funcionar com versões antigas e o fornecedor passou a novas versões. A obsolescência electrónica de equipamentos é um risco de grande dimensão quando tratamos de os embeber no desenvolvimento do produto muito especialmente se necessitamos de garantir o suporte destes produtos por longos anos.
Riscos relacionados com os Critérios de Aceitação – Uma causa importante de preocupação para o gestor de projecto está na definição no contrato de critérios de aceitação vagos ou pouco claros. Este também é um aspecto muito difícil de definir nos estágios iniciais do projecto quando se define a especificação do trabalho. Deve preparar um plano de teste da aceitação logo que os requisitos estejam fixos e a arquitectura de alto nível esteja realizada. Em alguns projectos esta importante questão só é tratada já tarde no projecto e esto deixa este exposto a um risco inaceitável.
Riscos da Regulação – A equipa de projecto tem de avaliar cuidadosamente os requisitos regulatórios e de certificação pra o produto e avaliar o seu impacto nos colaboradores do projecto, no desenho do produto, e no orçamento e tempo de realização do projecto. Se nada foi feito então estamos a enfrentar um risco maior, que deve ser regularmente acompanhado. Este tipo de riscos pode ter um alto impacto no projecto e reflectem-se no custo e no tempo com impactos significativos na satisfação do cliente / sponsor.
Riscos relacionados com Pessoas – Estes incluem conflitos, falta de competências, experiência, moral, motivação, relações da equipa, etc.
Riscos relacionados com a Experiência e as Competências – A disponibilidade de conhecimentos sobre a actividade pode ser um requisito importante em muitos projectos. Este conhecimento especializado pode ter a ver com a indústria ou com os domínios de tecnologia. O projecto pode necessitar destes peritos para desenhar um sistema que seja de confiança, que passe nos testes de certificação e que satisfaça as necessidades do utilizador final. Se estes conhecimentos especializados são necessário então desenvolve-se uma dependência e um risco associado. Um conflito com este tipo de especialização pode debilitar o projecto.
Riscos Políticos – Não podemos negligenciar este importante aspecto em qualquer projecto. Será que o projecto tem o compromisso adequado dos mais importantes apoios? E o sponsor do projecto será que ele tem o suporte e o financiamento da gestão? Quem é que sofrerá o impacto do projecto? E a sua colaboração é necessária durante a execução? Que precauções devem ser tomadas se algum stakeholder importante da organização cliente se recusar a cooperar? Quem é que deverá o cliente contactar se quiser levantar uma escalação? Foi criado um ponto de contacto entre a organização da equipa de projecto e a orgânica da organização cliente?
Riscos relacionados com a Garantia – Diferentes contractos têm diferentes cláusulas. O plano do projecto deve ter em consideração e planear para a os termos da garantia definidos para este projecto. As cláusulas de garantia, numa visão ideal, deverão descrever o tipo de suporte que será fornecido ao cliente / sponsor durante a fase de garantia. Não é anormal vermos cláusulas de garantia por múltiplos anos e estas colocam grande risco. Como é que se retém o conhecimento da equipa por este período de forma a cumprir os compromissos? Como se mantém as licenças das ferramentas durante este período? Como se enfrenta a obsolescência das ferramentas vitais e do equipamento?
Riscos relacionados com Penalidades – Muitos contractos incluem cláusulas de penalidades relacionadas com a performance da equipa de projecto. As estimativas iniciais devem ter em conta estas penalidades potenciais. Pode ser necessário entrar em linha de conta com a potencial perda de rendimento devido a penalidades de atraso criando uma margem adicional de contingência.
Riscos relacionados com a Qualidade – O que é que pode ir mal no que respeita à qualidade do produto? Os exemplos para pobre qualidade são pobre performance, interface difícil de usar, produto mal desenhado, reduzida confiança, etc. ajuda definir os parâmetros críticos para a qualidade para o produto logo cedo, como parte do âmbito e, em seguida, medir a qualidade do produto contra estes critérios.
Risco de Mercado – O produto foi construído mas o mercado coloca riscos significativos se o produto tem má ou errada funcionalidade, qualidade pobre, custos elevados, é difícil de usar, não passa nos testes de certificação, é difícil de produzir, é difícil de manter ou é atrasada a sua introdução no mercado.
Desastres Naturais – Estes riscos são muitas vezes ignorados pelos gestores de projecto porque lhes parecem estar para além da sua esfera de influência. Mas estes riscos devem ser registados no planeamento de grandes contractos e programas. Os planos de resposta ao risco devem ser documentados e em posição para que a equipa possa responder na eventualidade de ocorrer algum desastre. O propósito é minimizar o dano tanto quanto possível e por essa forma não é possível realizar a eliminação total do risco. A mitigação deste tipo de riscos são a diversidade geográfica, uma gestão robusta do conhecimento e documentação actualizada, para garantir um mecanismo de comunicação efectiva que possa em tempo sincronizar todos no mesmo propósito.
