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 artefatos 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 projeto. Pode funcionar como um embrião para a criação de um Registo de Riscos para utilizar em projetos ou uma lista de questões para colocar  em reunião de gestão de risco.
Então aqui vai:

Riscos relativos ao Âmbito – Deslizar potencial do âmbito porque os requisitos do projeto 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 projeto? 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 facto significativo. A falta de experiência anterior. Conhecimento experimentado da área de atividade, falta de adequadas revisões e verificações são as causas para estimativas inexatas. Ser pessimista faz-nos ganhar pontos e devemos quase ser paranoicos quando se trata da estimação do projeto. O otimismo mata, muitas vezes!

Riscos relacionados com Assunções – Será que definimos com clareza todas as assunções do projeto na especificação de trabalhos? E elas cobrem todos os aspetos importantes e as fases do projeto? Já foram documentadas as atividades a realizar se uma assunção se comprovar como errada e evolui para ser um risco para o projeto? Já fez a revisão com o cliente / sponsor as assunções e as contingências para cada uma? Todas as assunções, num projeto ideal, devem ser registadas e visitadas em cada relatório de status e revisão de projeto

Riscos relacionados com Dependências – O projeto 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 projeto. 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 projetos 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 selecionada 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 eletró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 projeto está na definição no contrato de critérios de aceitação vagos ou pouco claros. Este também é um especto muito difícil de definir nos estágios iniciais do projeto 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 arquitetura de alto nível esteja realizada. Em alguns projetos esta importante questão só é tratada já tarde no projeto e esto deixa este exposto a um risco inaceitável.

 Riscos da Regulação – A equipa de projeto tem de avaliar cuidadosamente os requisitos regulatórios e de certificação pra o produto e avaliar o seu impacto nos colaboradores do projeto, no desenho do produto, e no orçamento e tempo de realização do projeto. 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 projeto e refletem-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 atividade pode ser um requisito importante em muitos projetos. Este conhecimento especializado pode ter a ver com a indústria ou com os domínios de tecnologia. O projeto 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 projeto.

 Riscos Políticos – Não podemos negligenciar este importante aspecto em qualquer projeto. Será que o projeto tem o compromisso adequado dos mais importantes apoios? E o sponsor do projeto será que ele tem o suporte e o financiamento da gestão? Quem é que sofrerá o impacto do projeto? 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 projeto e a orgânica da organização cliente?

 Riscos relacionados com a Garantia – Diferentes contractos têm diferentes cláusulas. O plano do projeto deve ter em consideração e planear para a os termos da garantia definidos para este projeto. 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 projeto. 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 projeto porque lhes parecem estar para além da sua esfera de influência. Mas estes riscos devem ser registados no planeamento de grandes contratos 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 atualizada, para garantir um mecanismo de comunicação efetiva 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.

Valor Ganho (EVM) explicado

Muitos sistemas avançados de gestão de projeto utilizam o modelo tradicional de planeado vs real para acompanhar até que ponto o projeto está a decorrer (bem ou não tão bem) de uma perspetiva financeira. Contudo este modelo deixa de fora um elemento importante – o valor do trabalho já realizado.

 Quando o planeado vs real são os únicos valores acompanhados, só consegue ver se está abaixo ou acima do orçamentado. Diz muito pouco ou nada sobre o progresso daquilo que estamos a realizar. Por exemplo, podemos estar a gastar demasiado porque estamos avançados relativamente ao plano e fizemos imensos progressos.

Assim, aquilo que parece um problema é antes uma vantagem porque iremos terminar mais cedo e provavelmente abaixo do orçamento. Mas, se não existir nenhum sistema para atribuir valor às realizações não teremos nenhuma forma fácil de saber quais as implicações de ultrapassar o orçamento. Pode, claro, rever o plano e obter um sumário da percentagem de conclusão do projeto, mas este valor de percentagem, por si só, não está ligado aos valores baseados em custo do orçamento e custo real que estamos a acompanhar.

Para simplificar muito o conceito de valor ganho, podemos dizer que este irá atribuir um valor ao progresso que se realizou, com base no orçamento baseado no tempo.
Para ilustrar vamos usar um exemplo em termos de planeado vs real e de seguida vamos adicionar valor ganho para ver o que revela esta outra dimensão.

Temos um projeto de 10 meses que está planeado para gastar 1 Milhão por mês para um orçamento total na conclusão (BAC) de 10 M. Já passaram 2 meses e de acordo com os números de custo do planeado vs real já gastou menos 50% do que devia. Podemos assim assumir que o projeto está a decorrer bem, porque aparentemente está a gastar menos do que o que estava planeado.

Ao introduzirmos os números de valor ganho com base no progresso real do projeto obtemos uma nova perspetiva. Depois de 2 meses de trabalho, só foi completado 5% do trabalho. O cálculo simples para este cenário é 5% sobre um total de 10 M do orçamento serão 500 k. Este é o número do valor ganho.

O que é que este número de valor ganho nos diz acerca da presente situação do projeto?A despesa inferior realizada não é uma boa notícia para o projeto porque o cronograma está 75% para trás; o projeto está na realidade a gastar mais com base no trabalho realizado. O que parece bem numa perspetiva de planeado vs. real está longe de estar bem quando o valor do progresso é introduzido como valor ganho.Isto significa ainda que podemos ver o impacto para o projeto utilizando os cálculos standard de valor ganho. 

Estes sublinham a dimensão dos problemas em que o projeto pode estar envolvido.

• Orçamento na conclusão (Budget at Completion - BAC): 10 M
• Valor planeado até à data (Planned Value – PV): 2 M
• Valor ganho até à data (Earned Value – EV): 0,5 M
• Custo real até à data (Actual Cost – AC): 1 M
• Variância de custo (earned value – actual cost) = -0,5 M (significa gastar mais 100%)
• Variância de agendamento (earned value – planned value) = 1,5 M (1,5 meses ou atrasado 75%)
• Cost Performance Index (CPI): (earned value / actual cost) = 0.5 (por cada euro gasto ganhou 50 cêntimos)
• Schedule Performance Index (SPI): (earned value / planned value) = 0.25
• Estimado na conclusão (Estimate at Completion – EAC): (budget at completion / cost performance index) = 20 M
• Estimado até à conclusão Estimate to Completion: (budget at completion – earned value)/cost performance index = 19 M
• Tempo para completar = (10-0.5) /0.25 = 38 meses

Com base na performance corrente este projeto irá necessitar de 20 M (19+1) e 48 meses (38+2) para concluir.

Embora este seja um exemplo exagerado, muitos projetos sofrem algum nível de sobre despesa e sub-performance nas etapas iniciais. Isto é característico porque leva sempre mais do que o estimado com seguir ter todas as pessoas no site, o equipamento entregue e todos a trabalhar a bom ritmo.

Sem gestão do valor ganho, contudo, é impossível ter consciência do impacto potencial destes atrasos iniciais, que podem passar sem notícia significativa. A gestão pode não reagir da forma apropriada ou suficientemente cedo a estas tendências de forma a prevenir a ameaça de longo prazo ao sucesso do projeto.

Adaptação de post da Ten Six Consulting LLC.

Controlar os pedidos de Alteração nos projectos

Os pedidos de alteração quando um projecto se inicia são uma parte inevitável do projecto. Elas podem ser o resultado de mudanças externas no negócio ou podem ser mudanças internas requeridas porque os propósitos originais do projecto não foram claramente definidos ou compreendidos.

As mudanças requeridas por factores externos estão normalmente fora do controlo de um gestor de projecto e há muitas vezes poucas escolhas para as enfrentar. Muitos dos gestores de projecto experimentados terão já colocado em posição um processo no início do projecto para tratar destes pedidos e o plano será suficientemente flexível para tratar delas sem afectar o resultado final.

Mas os pedidos de alteração provenientes de factores internos devem ser tratados de forma muito diferente. Num projecto ideal muitos destes devem ser evitados garantindo que os objectivos do projecto estão bem definidos, que os requisitos estão documentados claramente, que foram comunicados a todos os stakeholders e que estes compreenderam o que é esperado do produto final. Claro que nós não vivemos num mundo ideal e por mais profunda e bem detalhada que sejam as fases iniciais do projecto tem de existir em posição um efectivo processo de controlo da mudança.

Nem todos os stakeholders e utilizadores conseguem visualizar o produto final pela leitura da documentação e estudo de diagramas. Mesmo quando são usados protótipos para melhorar a produção de requisitos, estes são, pela sua própria natureza, produtos não inteiramente funcionais e serão inevitáveis incompreensões e assumpções nos projectos complexos.

De qualquer forma, a boa documentação e documentação clara dos objectivos e requisitos de projecto irão minimizar o número de pedidos de alteração.

Então qual é a melhor forma de controlar os pedidos de alterações num projecto e continuar a realizar a conclusão do projecto dentro de um orçamento, de escalas de tempo e âmbito?

Distinguir entre o Necessário e o «Era bom ter»

Cada um dos pedidos de alteração deve ter uma justificação (que tal um «business case») que os suporte, tal como o projecto tem uma justificação. Claro, que esta justificação pode ser muito simples e breve, mas é um elemento necessário de todos os pedidos de alteração antes que possam ser considerados para inclusão no projecto.
O elemento mais importante deste «business case» do pedido de alteração é o benefício esperado o qual deverá indicar o valor que será adicionado ao projecto pela mudança. Isto indicará, por si próprio, quais as mudanças que serão provavelmente necessárias. É importante reconhecer que a descrição de alguns destes «business cases» pode não beneficiar necessariamente o projecto em termos de tempo e orçamento, mas sejam necessárias para que o cliente se mantenha competitivo no mercado.
Se os benefícios não forem especificamente declarados então deve discutir-se a questão com a pessoa que requereu a alteração para determinar se existe um genuíno benefício de negócio.
Soluções melhor desenhadas, ou mais bonitas, com funcionalidades e mais atractivas não são benefícios, a não ser que possam ser apoiadas pela forma como estas tiveram um impacto positivo no orçamento e no plano do projecto, ou, um impacto positivo nos esforços dos utilizadores em completarem actividades regulares. As perguntas mais vulgares a que deve responder o «business case» são:

• · Qual é a mudança externa no negócio de que resultou este pedido de alteração?
• · Quais os factores internos de que resultou este pedido de alteração?
• · Como é que esta mudança irá afectar o tempo que levamos a completar o projecto?
• · Como irá esta mudança afectar o produto final para o utilizador?
• · Que poupanças serão realizadas pela implementação desta mudança?

Evite desperdiçar Tempo e Esforço

A forma mais óbvia de evitar desperdiçar recursos valiosos de projecto em pedidos de alteração excessivos e em todo o processo de gestão da mudança, é garantir que o projecto se inicia com objectivos e requisitos claramente definidos. É também importante o critério que iremos usar para determinar o sucesso do projecto estar documentado sucintamente desde o início do projecto. Deve garantir que estes documentos são distribuídos aos stakeholders e utilizadores e que estão acessíveis cópias dos documentos.

Planeie actividades incluídas no plano do projecto para tratar dos pedidos de alterações e se este tempo foi ocupado adie os pedidos importantes para a próxima semana. Garanta que todas as partes interessadas sabem como trabalha este processo.

Tenha um Critério Claro de Aceitação e Rejeição

Defina um critério para avaliar estes pedidos que não serão, ou não poderão ser implementados. Quem faz o pedido tem de compreender o critério e este tem de ser consequente. O critério essencial, como já vimos, é ter uma justificação escrita, um «business case», que esclareça os benefícios. Se não tiver pode ser de imediato devolvido a quem emitiu o pedido. Não perca tempo atrás de quem fez o pedido para saber qual é a justificação escrita. A responsabilidade disso é de quem faz o pedido que o deve fazer logo desde o início (mesmo que depois devamos discutir e aprofundar a discussão sobre esta justificação).

Esteja preparado para fundamentar as razões para rejeitar um pedido de alteração com uma descrição bem pensada do porquê para não incluir a mudança. Mantenha-se na sua decisão a não ser que o sponsor do projecto queira aumentar o orçamento ou o tempo disponível no projecto.

Esteja, também, preparado para ser flexível e para negociar a substituição de uma actividade em favor da mudança quando não há nem orçamento nem tempo disponível.
Aplique sempre as melhores práticas de gestão de projecto em todas as áreas do projecto se quer aumentar as suas oportunidades de sucesso.

KPIs de Performance de Projecto

Quais são as mais críticas métricas de performance de projecto ? Com base no plano do projeto podemos identificar uma lista das mais importantes:

• Planeamento – planeado versus real – preferencialmente através do Valor Ganho

• Funcional – % desenhado, implementado, testado, produzido

• Realização em tempo – milestones planeadas versus as milestones reais

• Custo

• Custo planeado versus custo real

• Total Planeado na Conclusão versus Revisto ou estimado na Conclusão

• Crítico e outros defeitos – Planeado versus Real + tendência

• Recursos (Pessoas, Equipamentos)

• Recursos Planeados versus Recursos Reais

• Recursos Totais Planeado na Conclusão versus Revistos ou estimados na Conclusão

• Riscos – Novos, Fechados, Abertos + Tendências

• Questões – Novas, Fechadas, Abertas + Tendências

• Resultados – Planeados versus reias até à data

A standardização dos valores a reportar ajuda a mantermo-nos no caminho certo.
Naturalmente que todas estas métricas são quantificáveis. A informação qualitativa pode ser útil quando preparado no seguimento das métricas acima. Os problemas só começam quando as pessoas começam a esgrimir as suas declarações qualitativas e esquecem-se de colocar no relatório algumas das métricas quantitativas. ~

Luís Quintino

«Almofadas» de tempo no Plano

No mundo da gestão do projeto, as coisas correm mal! Esta é uma característica inerente aos planos, nunca correm conforme planeados. É por isso que bons gestores de projeto irão registar e acompanhar os riscos associados às atividades do projeto. Ainda assim, é difícil encontrar todos os riscos que podem estar escondidos dentro do cronograma do projeto. Por isso que alguns gestores de projeto adotam a prática de adicionar um ‘buffer’ de tempo na programação.

Sim. Tal como uma reserva de gestão ou reserva de contingência está incluída num orçamento como um item de linha, os gestores de projeto podem incluir uma «almofada» (‘buffer’) de tempo como um item de linha na programação. Então estes ‘buffers’ de tempo são uma forma geralmente aceite para explicar questões desconhecidas no cronograma. Se não usar esta «almofada» de tempo como item de linha o mais provável é que, involuntariamente, esconda estes ‘buffers’ de tempo dentro do plano de qualquer maneira.

Vamos discutir estas «almofadas» de tempo nos planos e a prática de as tornar visíveis. Temos de compreender que a sua utilização é outra ferramenta daquelas a que os gestores de projeto podem recorrer.

Deve ou não estar escondida?

A primeira questão é se esta «almofada» deve ser escondida ou deve estar visível. Para projetos de tempo e materiais, de forma definitiva, não faz qualquer sentido esconder este ‘buffer’ já que está garantido o pagamento de todo o tempo gasto no projeto. Mas para contratos de preço fixo, em que nos comprometemos a um custo fixo do projeto e uma data estabelecida de entrega, a existência de um ‘buffer’ escondido pode ser adequada. Geralmente num contrato de preço fixo não se mostra a margem de lucro e isto é uma prática standard aceitável. Da mesma forma pode ser aceitável não mostrar a margem de tempo para a data de fim do projeto.

Se não é utilizado um ‘buffer’ de tempo visível, como descrevemos, então o mais provável é estarmos a esconder ‘buffers’ não declarados. Por exemplo, podemos estra a exagerar o tempo e o custo de atividades individuais. Isto é conhecido como «engordar» as atividades. ‘Engordar’ é a adição de tempo e / ou custo a uma atividade para fornecer uma estimativa conservadora do tempo de atividade e / ou de metas de custo. Assim, «engordar» as atividades é uma das principais formas de ‘buffer’ escondido dentro de um cronograma.

Atitude perante o projeto

Outro processo é ser pessimista. Quando são fornecidas estimativas de duração de três pontos (otimista, mais provável, pessimista), usa-se os valores mais pessimistas para produzir um plano conservador. Mais uma vez, esta é uma forma de ‘buffer’ de tempo escondido. Outros processos, incluem, ignorar as curvas de aprendizagem ou a introdução de ‘ramp-up’ ou fatores de mobilização.

Embora, possa ser legítimo esconder ‘buffer’ num contrato de preço fixo, é recomendável que sempre torne os seus ‘buffers’ visíveis. É prática geralmente aceite que os gestores de projeto podem possuir ‘buffers’ de tempo para ajudar a ajustar para imprevistos.

Mais uma vez, a reserva de gestão de orçamento é uma prática amplamente aceite.

Mudar a atitude dos ‘donos de obra’

Nem sequer é grande extrapolação a partir daqui incluir também contingências orçamentais de tempo. Os ‘buffers’ de tempo visíveis também promovem a transparência e abertura num projeto entre o gestor de projeto e outras partes interessadas. O uso de ‘buffers’ visíveis também incentiva os membros da equipe do projeto a serem abertos e honestos sobre seus próprios ‘buffers’ de tempo.

O objetivo deve ser otimizar a programação para alcançar os objetivos de custo e tempo de uma forma atempada e eficiente. Depois, pode concentrar-se numa margem de segurança, no final da cadeia de projeto e utilizar apenas quando o risco se materializa.

Tipos de risco em projetos de construção

Tudo o que deu errado num projeto de construção é um risco potencial no próximo projeto. Muitos gestores de projeto desenvolvem instintivamente uma lista de riscos históricos e lições aprendidas e tomam medidas para minimizar a exposição a esses riscos no futuro. A importância de pensar na contingência como forma de enfrentar o risco conduz-me a desenvolver estas linhas sobre riscos em projetos de construção.

Os riscos variam de acordo com a indústria e até pelo tipo de projeto de construção, bem como pelo pessoal envolvido com o projeto. Um projeto de autoestrada ou ponte tem um grupo diferente de riscos do de uma instalação ou prédio, e os contratados selecionados podem ter diferentes graus de influência sobre o nível de riscos para o desempenho. Este é o primeiro tópico em que se deve basear a análise.

Riscos diretos

Se um dono de obra tentar economizar dinheiro em serviços de pré-construção, limitando a extensão da investigação de campo ou o desenvolvimento de dados executados, haverá um risco maior de descoberta tardia de problemas desconhecidos. A experiência e competência dos arquitetos e engenheiros que lidam com o desenho do projeto, bem como o seu controlo de qualidade no desenvolvimento de desenhos de trabalho, afetam diretamente o esforço de construção e, consequentemente, o risco associado aos planos e especificações.

Mesmo que o dono de obra tenha sido proativo na investigação pré-construção, há sempre o risco de condições imprevistas. Isso pode ser uma função do tipo de solo encontrado, do município do local e da sua cultura e histórico de manter bons registos de equipamentos obsoletos. Se a cidade na qual o projeto será construído tem um histórico de exigir que os empreiteiros removam todas as linhas subterrâneas abandonadas, há um risco muito menor de conflitos subterrâneos.

Riscos internos

A seleção da equipa do projeto pode impactar positiva ou negativamente na probabilidade de conclusão do projeto com sucesso. Os projetos que criam propostas que usam filosofias de aquisição permitindo que todos os contratados com capacidade financeira participem, provavelmente experimentarão um nível muito mais alto de risco para desempenho pontual do que uma filosofia de aquisição que requeira qualificação dos contratados propostos para garantir que eles tenham a experiência apropriada e recursos para construir o projeto. Um único subcontratado fraco num projeto aumentará o risco de desempenho e exigirá mais gestão do que o previsto. Se isso não for considerado, todos ficarão surpresos quando o subcontratado falhar e precisar aumentar ou corrigir o trabalho. Problemas relacionados com a gestão e possível rescisão de um subcontratante em falha causam geralmente sérios impactos negativos no projeto.

A reputação do gestor de construção (CM), bem como a cultura corporativa afetará o desempenho do projeto. Se o CM definir o sucesso com extensões de tempo mínimas como o único benchmark, provavelmente haverá mais conflitos e maior necessidade dos esforços de resolução de reclamações. Além disso, as capacidades de gestão do CM afetam diretamente muitas atividades do projeto, como a revisão de desenhos de trabalho e a resposta a solicitações de informações por forma a resolver questões sobre a construção.

O trabalho de fora ou de terceiros pode acarretar riscos significativos de influência no sucesso do projeto. Por exemplo, uma estação ferroviária ligeira a ser construída no topo de um parque de estacionamento em construção por um contratante diferente correrá um risco acrescido de conclusão em tempo. O projeto não tem controle sobre - e pouca capacidade de influenciar - a conclusão do estacionamento, que rapidamente se torna vital para a conclusão do projeto do metro ligeiro.

Riscos externos

A maioria dos projetos é afetada pelas condições meteorológicas locais, que, quando adversas, podem impedir significativamente o progresso. A maioria das especificações exige que o empreiteiro leve em consideração as condições climáticas locais normais no planeamento, o que inclui condições climáticas adversas normais, mas também permite extensões de tempo quando ocorre um clima adverso incomum. As melhores práticas exigiriam que o contratado pesquisasse os registros meteorológicos históricos locais para planear as condições climáticas médias de três a cinco anos. Diferentes partes do país e do mundo têm uma grande variação nas condições climáticas, portanto, planear ou não planear o risco do clima local pode afetar significativamente o sucesso do projeto.

Situações políticas locais, especialmente em climas políticos voláteis, podem dificultar todos os esforços para construir um projeto de forma eficiente. Países com sistemas políticos ou económicos instáveis ​​terão maiores riscos na conclusão de projetos bem-sucedidos do que aqueles com sistemas mais estáveis. Países ou regiões sujeitas a guerras, terrorismo, turbulência ou outros tipos de violência também correm maiores riscos para o sucesso do projeto do que outros. Se a administração local tiver uma política de exigir uma investigação profunda sobre questões ambientais ou burocracia rigorosa ou complicada, os projetos construídos nessa localidade terão um risco maior de licenças atrasadas e conflitos durante a construção.

Riscos de reputação

Outro grande risco em qualquer projeto é a experiência e a reputação da equipa do projeto para práticas seguras de construção. Violações de segurança e acidentes podem encerrar completamente uma obra. Mesmo pequenas falhas de segurança podem distrair a equipa do projeto e impedir o desempenho oportuno. Se um contratado tiver um histórico de segurança insatisfatório, o risco de atrasos por causa de violações de segurança é aumentado e deve ser levado em consideração durante o desenvolvimento do cronograma.

Em suma

Sem um cronograma de linha de base de caminho crítico bem projetado e desenvolvido, um processo de gestão de riscos não será efetivo. A análise de risco depende de cálculos precisos e consistentes da lógica da rede, da adequação do sequenciamento e das fases e de uma abordagem razoável para estimar as durações das atividades. O cronograma tenta prever quanto tempo levará para concluir uma atividade em algum momento desconhecido no futuro, com uma composição de equipa mais ou menos conhecida, com experiência variável e a trabalhar em condições desconhecidas.

A gestão de riscos reconhece a incerteza na estimativa de duração e fornece um sistema para debater estes e outros riscos que podem ocorrer durante o projeto. As distribuições de probabilidade são a melhor maneira de modelar as durações das atividades planeadas e um dos primeiros métodos usados de gestão da incerteza.

O que significa realmente controlo de projeto

O termo controlo tem vários significados. Aqueles que são novos na gestão de projeto ficam inicialmente desanimados usando o termo “controlo”, porque equivocadamente o equacionam com o conceito de autoridade.

No mundo da gestão de projetos, o controlo tem muito pouco a ver com dizer às pessoas o que fazer, ditando as ações ou pensamentos, ou tentando forçá-las a comportar-se de certa forma - todas as quais são interpretações comuns de controlo.

Na gestão de projetos, o termo “controlo” é muito mais análogo a dirigir um navio. Trata-se de fazer continuamente ajustes no curso com um objetivo principal em mente: trazer o navio para um porto seguro, como prometido no início da viagem. E a viagem do projeto bem-sucedida inclui a identificação de um destino específico, o mapeamento cuidadoso de uma rota para chegar lá, a avaliação da localização durante a viagem e a observação atenta do que está por vir.

Objetivo do Controlo do Projeto

Os gestores de projeto novatos (e alguns experientes!) costumam cometer o mesmo erro ao tentar manter o controlo dos projetos. Eles envolvem-se no aqui e agora - na medição e avaliação da situação imediata - com a exclusão de todo o resto. Eles calculam a posição atual e o quanto estão fora do curso. Isso é o que eles reportam ao gestor e prometem corrigir. Todo o foco deles consiste em permanecer na linha que eles traçaram do começo ao fim do projeto. Infelizmente, controlar o destino do projeto não é tão simples.

Como veremos, avaliar onde estamos em termos de onde deveríamos estar certamente faz parte do controlo geral e "voltar à rota" é quase sempre uma boa estratégia. Mas a missão principal é entregar o que prometeu, por isso deve pensar em "manter o controlo" em termos de minimizar a distância entre o local onde acaba e o aquele em que disse que acabaria.

Significa que o controlo geral do projeto exige um olho no futuro, como mostra a fórmula:

Variação atual calculada + variação futura estimada = variação final do projeto

Manter o adequado controlo requer que considere três parâmetros: (a) onde está, comparado com o local em que deveria estar; (b) o que há pela frente que possa afetá-lo; e (c) onde vai acabar, comparado com o lugar onde disse que acabaria. Tenha em mente que (a) e (b) são usados principalmente como funções de controlo interno (embora você possa optar por reportá-los fora da equipe). São usados para avaliar (c). Correndo o risco de ser repetitivo, o foco principal deve ser sempre avaliar onde acha que vai acabar.

Há duas razões para isso.

Primeiro, deve realizar uma ação corretiva inteligente e significativa com este ponto final em mente. Orientar o navio deve incluir mais do que apenas direcioná-lo de volta ao curso; também deve incluir o reconhecimento de que há um motivo à frente que terá que percorrer ou percorrer o próximo ponto de terra que começou desde que começou sua viagem. O futuro será sempre diferente do esperado no início do projeto. Os pressupostos serão revistos, as condições operacionais serão alteradas e novas coisas serão lançadas no caminho. Às vezes, as ações tomadas agora devem compensar as futuras fontes de variação, bem como as variações criadas pelo desempenho passado.

A segunda razão pela qual precisa concentrar-se no ponto final refere-se aos relatórios de gestão. Na maioria dos casos, o que provavelmente mais interessa à gestão é uma previsão de onde acha que vai acabar: esse é o tipo de informação de que precisam para gerir a empresa. É possível informar a gestão que está duas semanas atrasado ou que o valor de x € acima do orçamento pode ou não ter valor para eles. Relatar que espera que o projeto seja concluído com três semanas de atraso ou xxx € acima do orçamento tem muito mais probabilidade de ter valor.

O que Controla na realidade

Neste ponto, provavelmente vai dizer: "OK, então deveria estar focado no ponto final do projeto e deveria tentar" voltar à rota "e minimizar as variações. Mas o ponto final de quê? Voltar para que faixa de rodagem? E que tipo de variação falamos?” Todas são boas perguntas.

As respostas a estas perguntas conduzirão de volta à discussão sobre as dimensões do sucesso do projeto. A medida mais fundamental do sucesso do projeto refere-se ao cumprimento das metas acordadas em cada uma das dimensões. Estas são as metas que prometeu cumprir no início do projeto; esses são os alvos que você deve focar no controlo.

Dois dos alvos pertencem ao consumo de recursos:

• Cronograma: O projeto foi concluído no prazo? (Quanto tempo demorámos?)

• Custo: O projeto teve um custo? (Quanto gastámos?)

Os outros dois alvos estão ligados às entregas do projeto:

• Funcionalidade: Os entregáveis do projeto têm a capacidade esperada? (O que é que eles podem fazer?)

• Qualidade: Os resultados alcançados são tão bons quanto prometidos? (Qual a dimensão de bem pode ser alcançada?)

No que diz respeito a muitos gestores de organizações, o desfecho ideal ocorre quando um projeto responde a estes quatro objetivos exatamente como prometido. Embora os “alvos que são alcançados” sejam frequentemente caracterizados como desejáveis, atingir alvos fornece um nível de previsibilidade que a maioria dos gestores organizacionais valoriza. Os dois primeiros alvos (tempo e custo) geralmente recebem mais atenção; daí a frase muito comum "controlar no tempo e no orçamento".

Às vezes, no entanto, controlar o custo e o cronograma recebe muita atenção e o desempenho de entrega não é monitorizado tanto quanto deveria. Este é um grande descuido, em que deve concentrar-se em evitar.

Portanto, Controlo de projeto é. Realmente, minimizar a distância entre o prometido e o alcançado.

Elementos do processo de controlo requeridos

Os planos de projeto detalhados são criados para satisfazer dois objetivos básicos: primeiro, fornecer um mapa para a equipe do projeto acompanhar durante a execução do projeto; e, segundo, fornecer um instrumento que possa usar para avaliar se o projeto está ou não no curso. Em termos simples, não poderá manter o controlo sobre o projeto se não tiver um plano com credibilidade e devidamente detalhado.

A capacidade de avaliar o progresso do projeto, calcular a variação do plano e prever o futuro depende de vários elementos-chave do processo. Entre esses elementos estão os seguintes:

• Uma linha de base de medição, a baseline ou plano aprovado
• Processos e métodos para recolha de dados
• A capacidade de obter bons dados
• Enfase no cumprimento dos prazos
• Processos, ferramentas e métodos para analisar o desempenho passado, presente e futuro

Identificar o que pode atingir o projeto

Uma séria abordagem do Risco continua a ser a maior lacuna nos projetos no nosso país.A razão para isso entronca no deficiente conhecimento mas também na dificuldade de enfrentar a incerteza de forma prática.

O primeiro passo no processo de gestão de risco é descobrir o que enfrentamos. Que tipos de coisas ameaçam a capacidade de fornecer o que se prometeu? Tudo começa com a incerteza de não saber exatamente como as coisas vão acabar. Esta é apenas outra maneira de dizer que muitos aspetos dos projetos são imprevisíveis, apesar dos esforços para realizá-los. Eis algumas das áreas mais comuns de incerteza.

Área	Descrição
Âmbito	Extensão estimada do trabalho, capacidade de definir com clareza o trabalho, erros de desenho e omissões, mudança de âmbito dirigida pelo cliente
Tempo	Duração estimada do projeto, duração estimada de atividades, tempo para o mercado, data de lançamento, escala de revisões de gestão e aprovações
Custo	Custos estimados do projeto, custos de produção do procurement, custos de manutenção, Inflação, variações cambiais, limitações de orçamento
Tecnologia	Expetativas do cliente, probabilidade de sucesso, capacidade de escalação, sucesso do design, capacidade de produção
Recursos	Quantidade, qualidade, disponibilidade, competências adequadas, definição de funções e responsabilidades
Organizacional	Prioridades e conhecimentos do cliente, coordenação entre departamentos
Adaptação	Expetativas dos utilizadores, volume de vendas, demografia, qualidade, geografia, economia
Fatores externos	Ações e reações externas, regulação

Tabela 1 - Áreas típicas de alta incerteza

A partir destas fontes de incerteza, surgem questões. Estas são o que precisa descobrir, problemas potenciais específicos, quantos você puder imaginar. Mas como vai identificar problemas? Não há uma fórmula mágica para identificar possíveis ameaças ao seu projeto. Isso exigirá conhecimento específico do projeto, capacidade intelectual significativa e capacidade de especular. Hummm ... isso soa como uma excelente oportunidade para um evento de team-building.

Os melhores eventos de teambuilding são aqueles em que os membros da equipa expandem os conhecimentos uns dos outros e do projeto ao mesmo tempo. Identificar possíveis problemas como equipa é uma maneira ideal de conseguir isso. Caracterizo o efeito de eventos como este como construção da inteligência coletiva da equipa. Especificamente, a abordagem começa pela reunião de toda a equipe. Recomendo reservar de duas a quatro horas, dependendo do tamanho e da complexidade do projeto. Reúna cada peça Reúna toda a documentação que você puder e peça aos outros que façam o mesmo.

Documentos em background típicos podem incluir o Documento de Requisitos, o Documento de Definição do Projeto e o business case. De valor mais imediato, serão os documentos de planeamento do projeto, como a WBS, o cronograma de controle do projeto e a Matriz de Atribuição de Responsabilidades. Finalmente, estruture qualquer documentação de suporte relevante, como base de planos de estimativas, suposições de planeamento e o diagrama de rede usado para o desenvolvimento do cronograma.

O ponto central de tudo isso é que pretendemos que o maior número possível de documentos ajude e estimule o pensamento sobre possíveis problemas. Uma lista de verificação também pode ser bastante útil para estimular a especulação. Considere usar uma lista de verificação similar a esta quando realizar a reunião com a equipa.

Âmbito do Projeto _ Cliente adiciona âmbito ou funcionalidades _ Trabalho não pode ser definido com rigor _ Âmbito está subestimado _ Objetivos do projeto mudam	Instalações e equipamento _Indisponibilidade _Fraca confiança _Incompatibilidade com existente _Limitações proprietárias _Fraca flexibilidade _Má localização e espaço	Pessoal _Férias/Doenças _Família e outros _Interesses em conflito _Distrações externas _Questões éticas _Questões morais
Cronograma do Projeto _ duração subestimada do projeto _ Data de fim altera-se durante o projeto _ Data de fim irrealista _ Atraso nas aprovações _ Revisões da gestão atrasam projeto	Recursos _Mudança nos elementos da equipa _Financiamento _Custos/despesas incertos _Indisponibilidades _Prioridades desalinhadas	Interpessoais _Performance/ produtividade _Conflitos interpessoais _ Desenvolvimento _Má motivação e atitudes _Competências desajustadas
Materiais _ Fonte e disponibilidade _ Integração pobre com o existente _Deficiente confiança do fornecedor _ Confiabilidade do material _Qualidade fora do standard _Alto preço	Organizacional _Difusas funções e responsabilidades _Pobre delegação _Relações más entre unidades _Falta de coordenação _Conflitos entre unidades _Pobres comunicações _Limitações de política	Influências Externas _Meteorologia e desastres _Regulação e governo _Higiene e Segurança _Barreiras culturais _Tensões políticas _Mudanças económicas _Posição política desfavorável

Tabela 2 - Lista de verificação de questões

Relacione o máximo de problemas possíveis, com o uso técnicas de brainstorming. Embora não queira sufocar a criatividade, tente manter a lista com um tamanho razoável (talvez de 30 a 50, dependendo do tamanho e da complexidade do projeto).

Ao listar possíveis problemas que ameaçam o projeto, não perca de vista o conceito de incerteza. Lembre-se de que a falta de informação, conhecimento e compreensão é realmente o inimigo. Em outras palavras, pense nas maiores “ameaças” como aquelas que têm o maior potencial para o desviar o mais longe possível - numa direção desfavorável.