A Gestão do Portfólio de Serviços é mais importante que a Gestão do Portfólio de Projetos

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.

Principais Categorias de Riscos

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.

Melhorar a PREVISIBILIDADE do projeto

A previsibilidade do projeto consiste em prever com precisão o resultado de um projeto com antecedência suficiente para que seja possível identificar pontos de problema, tomar ações corretivas e manter o projeto em andamento.

 Para um portfólio de projetos, a ideia de previsibilidade pode ser expandida para todo o conjunto de projetos. Nesse contexto, a previsibilidade do projeto é aumentar a consistência e minimizar as surpresas num grande número de projetos.

Tradicionalmente, quando os líderes do setor procuram determinar o sucesso do projeto em todo o portfólio de projetos, concentram-se na variação dos resultados. No entanto, a variação não é um preditor confiável, pois mostra apenas a diferença entre custos reais e planeados e o cronograma. (De fato, a variação é aceitável em percentagens menores.)

Em vez disso, a previsibilidade do projeto concentra-se na pontualidade das informações num ciclo do projeto - quando mudanças prováveis ​​no resultado são identificadas.

No setor de engenharia e construção, por exemplo, estima-se que 98% dos megaprojetos excedam o orçamento em mais de 30%. Quanto disso pode ser evitado prevendo as ultrapassagens anteriores e resolvendo-as rapidamente?

PORQUE É IMPORTANTE A PREVISIBILIDADE DO PROJETO?

Criar processos e sistemas que melhoram a previsibilidade do projeto é crucial para o sucesso de uma organização de várias maneiras.

As previsões oportunas fornecem tempo suficiente para corrigir o curso, aumentando a probabilidade de atingir metas e reduzindo a variação dos resultados. A resposta a uma previsão preocupante pode ser descodificar alguns requisitos, modificar casos de negócios existentes ou até desfazer o projeto. No entanto, os líderes seniores anteriores têm a oportunidade de tomar difíceis estas decisões, melhor para a organização - isso pode levar a uma economia significativa de custos, além de um maior retorno sobre o capital empregado (ROCE) e economia de custos de oportunidade.

Outro motivo pelo qual a previsibilidade do projeto é importante é a credibilidade organizacional. Atrasos crónicos e excedentes de custos podem ter um impacto negativo na perceção da empresa. Para os empreiteiros em particular, quanto pior for prejudicada a reputação, mais difícil será obter projetos futuros. Se os problemas persistirem por algum tempo, pode até reduzir o valor da companhia e levar à queda de uma organização.

A previsibilidade garante que as organizações sejam conhecidas pela sua excelência na execução - não por apagar incêndios urgentes.

Os pilares da previsibilidade do projeto

Atingir a previsibilidade do projeto requer uma sólida base de boas práticas. É um processo contínuo que exige comprometimento de longo prazo, dos principais executivos a todos os funcionários da cadeia. Também requer incentivo e uma cultura de tomada de decisão baseada em dados.

Aqui estão os quatroelementos básicos da previsibilidade do projeto:

1. Gestão de Portfólio

O objetivo da gestão de portfólio de projetos (PPM) é identificar a combinação ideal de projetos que podem oferecer o máximo valor estratégico para a organização.

Para determinar o portfólio certo, os projetos são minuciosamente examinados, classificados para medir a potencial contribuição para a organização. Também ajuda a compará-los com indicadores anteriores para chegar a métricas iniciais do desempenho do projeto.

Analisar a disponibilidade de recursos é uma parte crucial deste pilar, pois é necessário entender a capacidade dos recursos e compará-la com a procura do portfólio. Dessa forma, torna-se possível estimar se há bloqueios iminentes durante a execução. Caso os recursos não estejam disponíveis conforme o esperado, as organizações podem planear adequadamente. Por exemplo, você pode contratar novas pessoas, mover recursos de outros projetos como solução alternativa, contabilizar mais orçamento para comprar novos equipamentos etc.

2. Gestão de Projetos e de Contratos

Se aprofundarmos ainda mais os portfólios, passamos à gestão de projetos e de contratos. No contexto da previsibilidade, o foco aqui é integrar as funções de mudança e risco com a restante plataforma do projeto. Este pilar é um reconhecimento da dinâmica da mudança nos projetos e uma mudança nas premissas que existiam no início ao decidir sobre o portfólio. Essas mudanças devem ser tratadas rapidamente, a fim de causar um impacto mínimo nos projetos em andamento.

Ao gerir as mudanças, riscos e problemas como parte de uma plataforma tecnológica holística, pode avaliar automaticamente o impacto no desempenho e nas previsões do projeto e, portanto, responder a estes o mais cedo possível. Também oferece uma oportunidade para ligar os dados do projeto ao vivo com métricas de previsibilidade.

3. Controlos de projeto e contrato

O objetivo desse pilar é impor controlos mais rígidos, com integração de funções de ponto a ponto do projeto, incluindo contabilidade, programação, gestão de recursos, compras e orçamento. Em vez de usar soluções em silos fragmentadas para cada uma dessas funções, ter uma solução consolidada (uma plataforma, um login, uma abordagem de banco de dados) garante que os dados sejam compartilhados entre diferentes departamentos do projeto e aumentando a visibilidade geral.

O uso da integração automatizada e nativa garante que os gestores de projeto recebem alertas quase em tempo real e análises de dados que podem conduzir ações corretivas em tempo útil. Além disso, fornece transparência e promove uma cultura que suporta a análise de cenários hipotéticos e a busca da raiz da causa das tendências.

4. Gestão de Performancce

Para derivar para um modelo de previsibilidade confiável, deve evitar métodos de previsão monolíticos e just-in-time em favor de métodos que constantemente ajustam as previsões e o fazem regularmente durante a execução do projeto.

Para conseguir isso, é importante recolher dados confiáveis de progresso ​​de fontes internas e externas em tempo real, agrupá-los e mapeá-los para o impacto real nos custos e excedentes de cronograma. Esse processo de medição de progresso com vários métodos permite que a fonte correta de progresso seja atribuída à entrega do projeto.

O outro aspeto da gestão da performance é fornecer métricas no momento certo: antes que seja tarde demais para reagir. A criação de ferramentas visuais, como painéis de controlo (dashboards), pode ajudar a partilhar continuamente informações com as partes interessadas relevantes.