cálculos financeiros, planejamento orçamentário, definição de custos A gestão dos custos do projeto é uma das seções mais importantes do PMBOK (Project Management Book of Knowledge) e procura, a partir de uma estimativa teórica e prática, determinar e controlar os custos envolvidos na execução de um projeto. Esta é uma importante área de conhecimento, uma vez que nenhum projeto pode ser considerado sem ter desviado recursos suficientes para sua execução.

Para isso, o tempo é um fator influente, uma vez que a estimativa dos custos que um projeto exigirá inicialmente funciona com cronogramas; ou seja, são propostas metas de curto prazo para cada fase.

 

Controle todos os aspectos financeiros de seus projetos com ITM Platform. Experimente gratuitamente e sem compromisso

Deve-se ter em conta que, mesmo considerando o termo total para a entrega de um projeto como uma variável independente, existem diferentes riscos associados aos custos como uma variável dependente. Ou seja: se for decidido realizar o projeto no menor tempo possível, o custo máximo será incorrido, o que requer uma coordenação impecável entre todos os processos e uma exposição de risco muito elevada na aparência de deficiências na coordenação. Se ao contrário, é decidido alargar o prazo, a exposição ao risco ambiental aumenta: as circunstâncias externas são mais susceptíveis de afectar o orçamento inicial.

Como estimar os custos de un projeto

As ações que giram em torno desta área vão além de uma mera estimativa quantitativa por um gerente ou equipe de gerenciamento de projetos, uma vez que os aspectos internos e externos que influenciam diretamente a realização do projeto devem ser cuidadosamente calculados.

Obviamente, os custos não podem ser estimados sem uma compilação exaustiva e exata dos requisitos. A primeira referência do gerente de projeto, portanto, é a Estrutura de Decomposição de Trabalho (WBS).

  • Defina o custo de cada requisito. Em muitos casos, esses requisitos terão um custo conhecido e um provedor confiável; em outros casos, serão mais difíceis de determinar e devem ser estimados aproximadamente;
  • Defina a quantidade de trabalho necessário para completar todos os requisitos e o custo por hora de cada tipo de especialista envolvido. Este cálculo serve de base para o custo humano do projeto.
  • A partir das duas somas totais, o gerente do projeto deve realizar os ajustes adequados relacionados às peculiaridades do projeto e seu plano, levando em consideração o termo do projeto e como ele afeta a organização das tarefas. Estimativa de custos. Isso implica o cálculo de várias circunstâncias e fatores disponíveis e previsíveis durante a sua validade, tais como riscos e aumentos de preços (se houver produtos envolvidos), aluguéis, materiais, equipamentos, instalações, etc. Para isso, uma "Linha de Referência" é criada com base no tempo estimado pelas ferramentas e recursos econômicos que serão fornecidos para cada atividade. Isso está conectado aos aspectos mencionados acima.

Quanto mais estreito o escopo, mais confiável será o orçamento para o projeto. Claro, o gerente do projeto não deve impor suas estimativas, mas confiar em uma equipe de especialistas e especialistas na área, que deve avaliar as tarefas que compõem o plano, especialmente em relação aos mais inovadores, e realizar essas avaliações.

Da utopia aos fatos

A área de conhecimento dos custos de um projeto não é exclusivamente financeira, mas requer técnicas, análises e conhecimentos especializados que permitam estar conscientes de todos os fatores que podem modificar um projeto. Entre eles, os cronogramas de execução, a avaliação de possíveis riscos, a coordenação de reuniões com as partes interessadas, nas quais pode ser necessário abordar sugestões que afetem o escopo ou modo de entrega, o respeito pelas políticas internas de uma empresa, atenção às condições do mercado, experiência em projetos passados semelhantes, etc. Entre os aspectos mais estritamente financeiros estão o controle cambial e os aspectos fiscais, que podem ser especialmente complexos em projetos internacionais, inflação e estrutura corporativa de controle financeiro.

Teste ITM Platform gratuitamente
Da mesma forma, converter informações em conhecimento requer ferramentas que facilitem uma abordagem dos fatos.

  • Unidades de medida: onde, dependendo do objeto a ser monitorado, será estimado se ele pode ser medido com unidades de tempo (horas, dias, semanas, meses), unidades métricas (metros, centímetros, milímetros, toneladas, litros) e até mesmo em unidades de pagamento (mensal, quinzenal, pagamento único, etc.).
  • Precisão: varia de acordo com o escopo do projeto, figuras redondas em torno de cada aspecto ou fase que dê certeza dos custos que serão necessários para cada um.
  • Limites de custo: é essencial determinar esse montante, de modo que, em cada revisão de custo, antecipadamente, seja condicionado o que será exigido em cada caso. Com esta ferramenta, pretendemos manter o investimento dentro dos parâmetros premeditados e, se não, tomar as ações corretivas correspondentes.
  • Medição do esforço premiado: são indicadores de execução que são descascados nos custos.
  • Gerenciamento de informações sobre gerenciamento de custos: as partes interessadas devem ser informadas de forma completa e regular da gestão que está sendo realizada, periodicamente (diariamente, semanalmente, quinzenas, mensalmente) e através de relatórios ou qualquer outra forma comum de comunicação.

Determinação do orçamento

Tomando como ponto de partida os custos relacionados a cada atividade, procedemos a adicionar cada uma das estimativas individualmente ou em conjunto, para estabilizar a linha ou custo de referência, com o único propósito de determinar o orçamento de um projeto, Isso influenciará os fundos que lhe são concedidos.

Controle de custos

É necessário monitorar o consumo de custos em qualquer situação do projeto e atualizá-los, se necessário, de acordo com o ajuste na linha de base de custo que foi criada. Qualquer aumento que seja considerado pertinente nos custos do projeto deve ser revisado sob uma perspectiva integrada das mudanças. No entanto, sua eficácia reside no gerenciamento da linha de base, que mantém o desempenho dos custos e estima os desvios que ocorreram.

O referido acima constrói o caminho para uma estimativa efetiva dos custos do projeto desde o início. O bom orçamento não é tão importante como a coleta de notificações de atividades com precisão. Do controle exaustivo dos desvios, é possível atribuir os recursos necessários para compensar a subforenda imprevista.

Receba as últimas notícias da ITM Platform

 

As áreas do conhecimento são organisadas por ordem de importância

As áreas do conhecimento são organisadas por ordem de importânciaAs 10 áreas de conhecimento reconhecidas no PMBOK são subdisciplinas práticas que podem ser caracterizadas por conjuntos de componentes metodológicos que cobrem todo o gerenciamento de projetos. Ao contrário das seis fases de um projeto, eles não têm uma ordem cronológica, mas são declarados por um critério de importância. Isso explica por que a integração aparece em primeiro lugar, uma vez que é a área que confere o projeto com existência contínua além de suas partes. Sem integração, o projeto simplesmente não pode existir: é uma questão de vida ou morte.

Controle os desvios de tempo, esforço e custo em tempo real con ITM Platform

Em seguida, vem a área de conhecimento do escopo do projeto. O conhecimento necessário nesta área permite gerenciar corretamente o escopo do projeto, de modo que as duas condições complementares e essenciais sejam atendidas para que o resultado esperado possa ser obtido:

  • O projeto inclui todo o trabalho necessário
  • O projeto não inclui nada que não seja necessário

Por outras palavras: enquanto o gerenciamento de integração envolve a criação e manutenção do projeto como um artefato complexo, o gerenciamento do escopo envolve o controle das relações causais dos componentes do projeto com o resultado. Ou seja: a partir do efeito esperado, todos os fatores causais que levam à sua produção estão incluídos.

Os benefícios são claros: o gerente, diretor ou líder de um projeto aumenta suas chances de sucesso se você considera essas boas práticas de gerenciamento que facilitam a correção estruturada de atividades de trabalho.

É importante estar ciente de que, precisamente por causa da relação entre os componentes do projeto e seu resultado, o escopo pode se referir a:

  • o escopo do produto que será entregue. É muito mais orientado a definir os requisitos funcionais que devem caracterizar o resultado.
  • o escopo do projeto, um termo mais amplo e prolongado no tempo que às vezes inclui o anterior. O escopo do projeto aponta para o "como" ou para o trabalho em geral que deve ser feito para fechar o ciclo, levando em consideração tanto os riscos quanto as limitações e as alternativas de gerenciamento

Gerenciamento do escopo do projeto

O escopo do projeto é o resultado do tempo e dos esforços investidos de acordo com o famoso triângulo. Como é sabido, as dimensões das três variáveis são interdependentes, de modo que o aumento de escopo pode ser resolvido com um projeto mais longo ou com a inclusão de um maior número de recursos. Assim, os processos de gerenciamento de escopo do projeto são as principais ferramentas para dimensionar adequadamente o triângulo. Além da criação de um plano de gerenciamento de escopo, os processos incluem:

  • Compilação de requisitos
  • Definindo o escopo
  • Criação da Estrutura de Decomposição de Trabalho (WBS)
  • Validação do escopo

É claro que, como veremos em artigos futuros, o gerenciamento de riscos tem um papel primordial na proteção de alcance, prevendo possíveis situações que podem alterá-lo e projetar respostas que atenuem o dano.

Ajuste bem a definição do escopo

Definir esta variável melhora a estimativa do tempo, custos e recursos necessários para suportar medições de desempenho subsequentes. Desta forma, é realizado um gerenciamento de comunicação efetivo que evita a expansão ou deslizamento do escopo, para atender aos requisitos do produto e ao plano de gerenciamento de projetos.

Declaração do escopo do projeto

Esta declaração detalhada inclui os seguintes aspectos:

  • Objetivos
  • Escopo e qualidades do projeto
  • Requisitos, condições ou recursos de entrega do projeto
  • Límites
  • Resultados
  • Critérios de aceitação
  • Orçamento
  • Organização inicial
  • Riscos definidos iniciais
  • Marcos de programação ou datas importantes
  • Estimativas de custo

Estrutura de decomposição do trabalho

Conhecida em inglês como Work Breakdown Structure ou WBS, esse método lógico de quebra do trabalho é fundamental porque, pela declaração de escopo, ele consegue agrupar tarefas em um diagrama gráfico, para planejar um calendário, os custos estimados, recursos necessários e, até, possíveis cenários de mudança e desvio.

EDT, Estrutura da avaria do trabalho

Bases da WBS

A WBS é a alma do planejamento, já que toda a equipe participa da sua definição, de modo que nenhuma tarefa ou nível é deixado fora da subdivisão.

A idéia é identificar os entregáveis e subprojetos para poder fazer as tarefas mais tarde com maior capacidade de controle e de forma mais ajustada às capacidades de cada seção de trabalho.

Diccionario WBS

A fase inicial para realizar a gestão do escopo do projeto culmina com este documento imperativo que contém a declaração do escopo e estrutura de decomposição, para descrever detalhadamente os pacotes de trabalho e de acordo com os objetivos, atribuições, datas, os critérios de aceitação, os pressupostos, os riscos, os recursos atribuídos e as dependências.

Esta ferramenta de consulta permanente mostra as diferentes relações entre os pacotes de trabalho e consolida a linha de base do escopo para garantir que o projeto permaneça no caminho estabelecido, a menos que, para circunstâncias específicas, o cliente decida modificar ou atualizar orçamentos teórico e factual para direcionar o projeto com uma nova perspectiva de escopo.

Recomendações

Cuidado com a síndrome da lavanderia

Um dos mais comuns situações infelizes na direção dos projetos é a corrupção do escopo, também conhecida como "síndrome da pia" (kitchhen sink syndrome). A corrupção do escopo é um dos riscos mais comuns de um projeto e é especialmente comum no caso de grandes projetos ou projetos inovadores. No último caso, por exemplo, é compreensível que alguns dos requisitos básicos do EDT sejam caixas negras com uma complexidade maior que a originalmente estimada.

O realismo não é uma perda de tempo

Portanto, as melhores práticas que podem ser recomendadas são que os requisitos coletados ao longo do plano do escopo sejam realistas. Pode parecer inoportuno perder tempo entendendo o dimensionamento de uma área secundária do projeto, mas se houver outras áreas com dependências deste ultimo o caminho crítico pode ser afetado, o atraso na iniciação do projeto certamente vale a pena ser compensado com uma quantidade menor de atrasos.

Esta comunicação descritiva e permanente com as equipes de trabalho e as partes interessadas, em geral, permitirá que você tenha um melhor gerenciamento de projetos. Não pense que seja uma perda de tempo falar com um técnico sobre os aspectos aparentemente insignificantes de suas operações diárias: isso irá ajudá-lo a ter um controle muito maior sobre seu alcance.

Controle, controle, controle

O monitoramento de projetos requer a adoção de ferramentas para detectar desvios imediatamente em relação ao tempo estimado. Se você não tem visibilidade sobre o tempo trabalhado pelos membros do projeto, ou se sua gestão financeira não está devidamente relacionada com o progresso do projeto, você pode beneficiar imediatamente das vantagens de ITM Platform.

Receba as últimas notícias da ITM Platform

 

collection of colorful vector icons in modern flat design style on education and learning theme isolated on white background

Os especialistas são um grupo muito desejado pelos gerentes de projetos e, em geral, por todas as equipes de projetos, porque podem fornecer conhecimento especializado e aplicá-los na resolução de um problema ou na análise de uma tecnologia complexa.

Muitas vezes, o conhecimento especializado transforma os especialistas em consultores de primeira classe. Sua especialização pode ser direcionada para uma área de conhecimento, um processo, um sistema, um software ou uma equipe. A perspectiva do especialista é insubstituível e pode informar o conteúdo do projeto ou alterar a mesma execução.

Como encontrar o equilíbrio de um especialista

Qualquer especialista consultado para um projeto com certeza passou muito tempo especializando-se, no entanto podem existir perfis diferentes, nem todos eles acadêmicos. É possível que eles tenham trabalhado o tempo suficiente para dominar seu campo na prática, ou que tenham estudado uma área com grande profundidade. Se eles são funcionários da sua empresa, podem ser programadores de software, técnicos ou engenheiros, mas também contabilistas ou advogados. Fora de sua organização, eles podem ser representantes públicos, ambientais ou acadêmicos.

Integre especialistas no seu ambiente de ITM Platform

Qual o valor que um especialista pode trazer?

As contribuições e os comentários de um especialista, se chegarem a tempo, podem mudar a direção e o escopo de um projeto. Talvez a sua compreensão dos sistemas e processos afetem a abordagem de equipe, ou podem explicar as limitações do projeto em relação às condicionantes ambientais cujas implicações não eram conhecidas. Na verdade, sem o conhecimento e a experiência dos especialistas, é difícil saber com o que você está trabalhando.

Quando os especialistas podem ser um risco?

Como mencionado, os especialistas passaram muito tempo (estamos falando de dezenas de milhares de horas) para treinar e especializar-se, assim é possível que tenham opiniões e posições muito fortes que não estão dispostos a discutir. Ou que eles não tenham muito a ver com o próprio projeto.

Por exemplo, o especialista poderia dominar os detalhes de um sistema técnico usado na sua organização, mas ignora como ele interage com a maioria dos softwares modernos, tais como aplicações e API de redes sociais, ou como pode ser integrado para fornecer uma experiência de usuário unificada.

Por outro lado, o especialista pode saber muito sobre um produto e pouco sobre o público que você quer atingir. Isso envolve riscos ao tomar decisões ou debater questões que afetam aspectos do comportamento demográfico.

A moral é que cada vez que você trabalha com um especialista, deve levar em conta seus possíveis vieses e comparar o valor que o conhecimento trará. É uma situação de busca de equilíbrio: não tome tudo ele disser como valor nominal, mas lembre-se de que ele poderá ter contribuições únicas para seu projeto.

Táticas para enfrentar o viés dos especialistas

Aqui estão algumas coisas a ter em mente se você estiver trabalhando com especialistas:

  1. Evite todo o viés

Tenha em mente que as opiniões de um especialista podem não levar em consideração a posição relativa deste tipo de conhecimento no contexto do seu projeto. O seu conhecimento e todos os resultados da pesquisa devem servir de complemento ao conhecimento e ao know-how da equipe.

Além disso, os preconceitos de especialistas também podem causar que o objetivo do projeto seja distorcido. Não deixe que os resultados e a finalidade do projeto sejam distorcidos!

  1. Teste a investigação antes de validá-la

Por mais tentador que seja, envolver o especialista desde o início do projeto para que ele exerça sua liderança e ajudar a orientá-lo, é conveniente que eles não participem nas fases de execução. Isso permitirá que outra pessoa retome suas contribuições e pesquisas, levando os aspectos que valem a pena e eliminando (ou polindo) os desvios.

  1. Tenha um grupo de especialistas diversos

Outra boa ideia é ter vários especialistas para trabalhar juntos. A ideia é ainda melhor se, além de ter opiniões diferentes, seus perfis são diferentes. Isso fará com que as contribuições sejam equilibradas e as chances de um viés individual exceder menores.

Embora não seja fácil (ou barato) encontrar dois ou três especialistas, tente fazer com que seu especialista, pelo menos, trabalhe em estreita colaboração com sua equipe para entender as motivações do projeto e aplicar seu conhecimento e experiência de forma construtiva.

O gerenciamento de especialistas e partes interessadas absorve a maior parte do tempo de um gerente de projeto. Muitas vezes, de fato, os aspectos mais difíceis e cruciais de um projeto estão relacionados à liderança das pessoas, à comunicação e à integração de diferentes pontos de vista.

Este artigo foi escrito pela Southern Cross University em colaboração com a ITM Platform.

Receba as últimas notícias da ITM Platform

 

banking icons thin line set. currency operations, bank building, check, wallet and credit card, paper cash and coins in hands, pos machine. flat style color vector symbols isolated on white.

Os serviços financeiros são um termômetro infalível do seu tempo

Como fontes de financiamento e garantias, a cultura produtiva a qualquer momento se reflete em serviços como bancos comerciais ou seguradoras.

Em tempos de colonização europeia, as grandes aventuras de exploração só foram possíveis graças à emissão de empréstimos pelos grandes banqueiros da época.

No oeste americano, no início do século XIX, os bancos operavam com regulação mínima. Para gerar confiança em seus usuários, o banco foi muitas vezes a instituição mais reconhecida de vilas povoaçéoes inteiras. É neste momento que a comunicação remota foi feita pelo código MORSE e as linhas de trem forçadas a coordenar os horários em territórios remotos.

Monitorize a contribuição de seus projetos de tecnologia para o desenvolvimento do negócio com ITM Platform.

Hoje em dia, a necesidade de confiança e garantias não mudou, mas os meios  para a garantir necessitam outro tipo de tecnologia mais actual: a fabrica é código.

Entidades que fornecem serviços financeiros a usuários privados movem trilhões de dólares em todo o mundo, e incluem principalmente bancos comerciais e companhias de seguros. A transição para usuários cada vez mais digitais forçou esse setor não apenas a fornecer serviços bancários on-line, mas a dar acesso a esses mesmos serviços em aplicativos móveis.

A pressão sobre os bancos para modernizar os sistemas de TI é enorme.

E não se trata apenas de projetar um aplicativo bancário atraente e útil.

Um aplicativo de banco comercial móvel apenas é possível como resultado de dezenas de projetos diferentes, tais como:

  • Transferências de dinheiro para outras entidades bancárias
  • Sistema de autenticação seguro por impressão digital
  • Gerenciamento de contas, com recuperação de informações históricas e atualização permanente com os últimos movimentos
  • Navegação GPS para encontrar o ATM ou agencia mais próxima
  • Visualização de informações

Tudo isto não leva em consideração todas as infraestruturas tecnológicas com as quais o aplicativo bancário on-line deve ser conectado para serem lançados, nem as obrigações legais e de conformidade a que esses tipos de operações estão sujeitos, incluindo a proteção de dados durante sua recuperação, tratamento, armazenamento e comunicação.

A concorrência é feroz: de acordo com um relatório da Ernst & Young lançado em 2016, na maioria dos países pesquisados, o público em geral se baseia mais nos serviços bancários móveis de cadeias de supermercados ou bancos nativos digitais para as aplicações bancárias on-line dos bancos tradicionais.

Se esses projetos não fossem gerenciados de forma coordenada, seria impossível garantir o serviço. Além disso, seria louco pensar que funcionaria no momento do lançamento. Assim sendo, todas as empresas de serviços financeiros precisam gerenciar seus projetos de forma coordenada.

Isso significa que, sem abordar todas as repercussões e conexões entre o novo aplicativo e os sistemas existentes, e sem planejar os projetos de forma coordenada com base nessas conexões, em algum momento, encontraremos esta mensagem ao abrir nosso aplicativo de banco pessoal online:

"O serviço está suspenso por razões técnicas. Lamentamos o inconveniente. "

Se esse ponto for atingido, a coordenação falhou. É hora de abandonar a gestão dos projetos para chegar à gestão da crise.

A mensagem tem tantas causas como variações: problemas de login, falhas na atualização dos dados, obstáculos para a realização dos procedimentos.

No entanto, o resultado é o mesmo: perda de clientes e reputação.

Portanto, para as organizações que conseguem coordenar seus projetos, as vantagens competitivas aparecem de uma só vez. Além disso, atraídos por uma experiência de usuário reconfortante, novos clientes chegam em bandos.

Os serviços financeiros e a gestéao de projetos

Para evitar sustos como os da mensagem precedente e construir uma estratégia robusta de entrega de tecnologia, a responsabilidade do CIO de um banco não tem nada que invejar à do general de um exército. A fim de coordenar as atividades sob sua responsabilidade, esses perfis devem se concentrar, pelo menos, em 6 grandes responsabilidades:

  • Desenvolver projetos para todas as unidades de negócios da organização com equipamentos e financiamento limitado, respondendo frequentemente às demandas diretas de novos projetos internos
  • Contribuir consistentemente para metas de produtividade
  • Conduzir a digitalização do portfólio de serviços
  • Modernizar os sistemas de informação, que muitas vezes têm dé A transição é difícil, mas sem ela a velocidade de resposta do todo pode ser comprometida. Além disso, problemas de compatibilidade com versões anteriores podem surgir assim que haja fortes demandas para implementar novas tecnologias para o usuário, como o pagamento direto por celular.
  • Reduzir os eventos imprevistos que impedem o planejamento ativo e "apagar os incêndios" efetivamente
  • Usar medidas confiáveis ​​para saber se as equipes estão trabalhando nos projetos certos

As 11 perguntas sobre projetos em serviços financeiros

Essas responsabilidades exigem acesso a informações conjuntas, como a fornecida por ferramentas de gerenciamento de portfólio, e que pode ser resumida em 6 questões básicas:

  • Que projetos estão sendo implementados atualmente?
  • Quais os projetos planejados?
  • Quais são os recursos disponíveis?
  • Existem limites ou restrições sobre o uso desses recursos?
  • Quais outros projetos podem ser implementados com a capacidade atual?
  • Quais são as dependências entre projetos?
  • Quais são as opções para resolver conflitos para o uso de recursos entre diferentes projetos?

Além disso, existem outras questões cuja resposta provavelmente requer reuniões e deliberações. As seguintes 4 são apenas exemplos.

  • Existem propostas de projetos não aprovadas que merecem esforços em vista da situação atual ou que tenham sinergias com outros projetos já iniciados?
  • Dado o acompanhamento dos projetos, é conveniente cancelar qualquer um dos projetos em andamento?
  • Os recursos foram planejados de acordo com as prioridades do projeto e as competências específicas do trabalho?
  • Existe alguma revisão de objetivos e prioridades que afetam a execução dos projetos?

Para responder adequadamente a essas questões, é necessário utilizar o portfólio de projetos da organização como um repositório de ideias e propostas que são avaliadas, analisadas e iniciadas de acordo com um ciclo constante.

Em muitas organizações em outros setores, o comitê de gerenciamento de portfólio é composto por diretores de várias áreas, cada um dos quais fornece contribuições para projetos prioritários. Este modelo também pode ser implementado em bancos ou seguradoras; O fundamental é encontrar o equilíbrio entre os critérios de viabilidade técnica dos gerentes de TI e a visão de negócios.

Nessas bases, os projetos de digitalização, inovação e desenvolvimento comercial de qualquer entidade de serviços financeiros serão protegidos por um sistema de governança robusto com garantias de sucesso.

Se gostou deste artigo, poder ler outros relacionadosno nosso Blog: 

Ferramentas para gerenciar um ambiente de multiprojeto

Por que o MS Project empalidece perante uma ferramenta na nuvem?

Receba as últimas notícias da ITM Platform

 

administrador do sistemaNão é novidade que os Chief Information Officers possam ser considerados diretores de todos os projetos tecnológicos de uma organização.

Na verdade, em meados dos anos noventa, pensava-se que os gerentes de projetos não podiam se limitar a realizar tarefas, mas tinham que ter um compromisso abrangente com a estratégia de sistemas da organização. Foi então que algo semelhante foi defendido: que os diretores do PMO têm um papel muito parecido com o do CIO.

Com a consolidação de escritórios de gerenciamento de projetos em todos os tipos de organizações e o surgimento de boas práticas de start-up e operação, os PMOs se tornaram no modelo claro para a gestão de projetos internos em grandes corporações. Portanto, vale a pena lembrar a afirmação oposta: que os CIOs dirigem um PMO de projetos de tecnologia interna

Controle sua estratégia de sistemas com ITM Platform

A falta de definição do CIO: entre estratégia e dia-a-dia

É bastante difícil definir detalhadamente o papel de um Diretor de Tecnologia (CIO). Há aqueles que dizem que ele é simplesmente um diretor de sistemas com muito dinheiro. Embora funcione como uma piada, é uma declaração muito imprecisa: qualquer CIO é o principal responsável pela estratégia, práticas e políticas dos sistemas de informação de uma organização.

Dito isto, a vida cotidiana de cada CIO é muito diferente, variando de acordo com a indústria, o país, o tamanho da empresa e a personalidade dos gerentes que estão acima.

De fato, as expectativas da alta gerência do que um CIO deve fazer são, provavelmente, o aspecto mais importante. É muito diferente para um CEO querer um CIO para materializar a visão do negócio graças a um especialista em tecnologia que confia em um gerente de sistemas para responder o mais rápido possível a todas as suas exigências. Essa é a grande diferença entre um CIO como gerente sênior e um CIO como mera pessoa responsável. Exagerando um pouco desta distinção, pode-se dizer que existem dois tipos de CIO: aqueles que não têm tempo para supervisionar as operações diárias e aqueles que não encontram tempo para deixá-las.

Mas, no final, cada CIO está entre dois mundos: a alta administração, que se concentra na visão de longo prazo e na criação de valor para os investidores; e o dia-a-dia da gestão tecnológica, que inclui aspectos como:

  • Compra de tecnologia
  • Limite dos danos e planejamento face a possíveis falhas
  • Planejamento do pessoal, incluindo treinamento
  • Criação de novos sistemas
  • Integração e mantimento de sistemas existentes

Quando a organização é pequena o suficiente, o CIO pode lidar com todos esses aspectos; mas, a partir de uma certa dimensão, deve contar com um sistema de delegação, estabelecendo regras e procedimentos para que outros assumam essas responsabilidades em um quadro unificado.

A aspiração de todos os CIOs é provavelmente estabelecer esse quadro de referência para poder se dedicar ao que é interessante: direcionar a estratégia e se envolver com a gestão da empresa com a qual os seus homólogos em grandes multinacionais, como as grandes empresas farmacêuticas, contam. Nas palavras de Paul Burfitt, CIO da Astra Zeneca até 2006, o trabalho do CIO consiste em criar quadros de referência (políticas, padrões e estratégias) que permitem que cada subsidiária atue por conta própria, de forma habilitada. Enquanto isso, o CIO dedica-se a projetar prioridades, objetivos e metas, combinando, em qualquer caso, a perspectiva de negócios e a perspectiva dos sistemas de informação.

Por que o CIO possui um PMO de projetos de sistemas

Nesse difícil equilíbrio entre o dia-a-dia e a estratégia é onde a comparação do CIO com o líder de um PMO se encaixa perfeitamente.

É fácil entender se fizermos a seguinte pergunta: quais são as responsabilidades do CIO no gerenciamento de projetos?

  • Equilibrar demanda com capacidade

Os pedidos de melhorias em sistemas informáticos internos, bancos de dados, módulos de gerenciamento, CRM, etc., crescem mais rapidamente do que a capacidade de gerar tais melhorias. O desenvolvimento de novos softwares e a integração de diferentes tecnologias são processos longos e caros.

Portanto, uma das primeiras responsabilidades do CIO é garantir que haja a capacidade de cobrir os projetos que vão começar e que os recursos atribuídos tenham o conhecimento técnico necessário. Daí a importância do planejamento abrangente de recursos.

  • Saber dizer “Não

Como a demanda por trabalho técnico sempre excederá a capacidade, cada CIO deve saber como dizer não às ideias, pedidos e requisitos. Para isso, é essencial ter diretrizes e políticas que permitam priorizar e levar a tecnologia da organização ao seu próximo estado.

Do mesmo modo, os PMO estratégicos oferecem instrumentos e ferramentas para a tomada de decisões, sobre quais projetos devem ser iniciados e quais não são suficientemente importantes para passar de um mero rascunho. Ocasionalmente, o PMO até tem autoridade suficiente para tomar tais decisões.

  • Gerar as expectativas adequadas

Quando as políticas internas e os planos estratégicos são comunicados adequadamente, diferentes departamentos são mais propensos a saber o que esperar de seus pedidos e que tipo de ideias provavelmente serão incluídas no portfólio do projeto.

  • Envolver os departamentos que solicitam a mudança

A cultura ágil mostrou que o sucesso dos projetos de tecnologia interna depende do grau de comprometimento dos patrocinadores do projeto. Para que a estratégia de tecnologia corresponda às perspectivas de crescimento, muitos CIOs garantem que cada departamento é responsável pelo sucesso das ideias que propõe. Desta forma, são evitados pedidos desnecessários e ideias cujas consequências não foram devidamente analisadas.

Um PMO tem responsabilidades muito semelhantes, como órgão de coordenação para que todas as partes envolvidas nos projetos colaborem de forma proativa e ofereçam mais contexto de negócios aos gerentes de projeto para que eles compreendam a motivação por trás de cada novo requisito.

Em suma, tanto o CIO quanto o PMO têm funções de coordenação, monitoramento, unificação, avaliação e seleção do portfólio de projetos de uma organização. A diferença fundamental entre os dois é que o PMO se baseia muito nas metodologias de gerenciamento de projetos, enquanto o CIO trata mais do que a organização exige, sua estratégia e os desafios tecnológicos. Ambos os papéis podem ser combinados de forma produtiva.

Como se isso não bastasse, as responsabilidades também se aproximam em termos de treinamento, aprendizado contínuo e transferência de conhecimento. Como tanto o CIO quanto o PMO têm uma dimensão transversal, a rotina, o conformismo e os compartimentos estanques são seus grandes inimigos.

Benefícios de tratar o trabalho do CIO a partir do PMO:

Os CIOs que decidem adotar a ideia de ter um PMO, mesmo que seja embrionário, poderão beneficiar dos seguintes elementos:

  • Adoptar metodologias de portfólio para monitorar, avaliar e selecionar projetos
  • Ter critérios claros para priorizar o trabalho de acordo com o valor que ele traz para o negócio. Um PMO ágil pode gerenciar a acumulação de requisitos dinamicamente, adaptando-se às circunstâncias para maximizar o valor entregue ao cliente.
  • Além disso, a governança dos projetos representados pelo PMO permite ao CIO deixar o escopo do trabalho reativo para defender a importância estratégica de seu perfil, abordando o CTO. Embora isso seja para outro artigo, trata-se de imaginar o futuro e avançar para uma visão da mídia que dá o domínio da tecnologia.

Claro, a relação entre o CIO e o PMO é variável. Pode ser uma dependência direta, mas também há organizações onde o CIO aconselha o PMO: ser o proprietário da estratégia e ter um contato muito mais direto com os clientes e gerar valor, pode ajudar o PMO e os gerentes de projetos que são colocados no lugar dos clientes e tornam concreto o objetivo do projeto através da empatia.

Objetivo: Entrar no comité de direção

De acordo com um estudo Russam GMS, apenas 2% dos comitês de gestão possuem um CIO. E isso apesar de ser uma aspiração geral deste perfil com benefícios claros ao decidir o curso de um empreendimento comercial.

O isolamento do mais alto representante dos sistemas de informação em relação à alta administração é outro ponto de similaridade com os PMO: muito poucas organizações admitem o diretor do PMO no comitê, considerando tudo o que tem a ver com a gestão de projetos em um nível inferior ao executivo.

No entanto, tanto o CIO quanto o PMO implementam suas capacidades organizacionais máximas quando sua missão é projetar e manter sistemas de governança.

Quando a governança do projeto é incorporada ao comitê de direção, o desempenho dos projetos e sua contribuição para os objetivos da organização são maximizados.

Quando o CIO que se junta ao comitê não só supervisiona a governança tecnológica, mas está envolvido na governança dos projetos, a organização irá lançar as bases para atingir a máxima solidez como ator digital. Um verdadeiro quebra cabeças para a concorrência.

Receba as últimas notícias da ITM Platform